Re: Wait for interface existence?

>> I notice you completely ignored my stated desire (in text I cut when
>> trimming, above) to shut it down once it has found the interfaces.
> So *why* do you feel the need to shutdown ifwatchd.

So it doesn't remain forever cluttering up the process table.

Either you need a way to shut it down or you need a way to not start a
new one each time you want to wait; the latter is what led to the
"single ifwatchd with additional tooling to keep state &c".

> Well, it's the right answer because that's how ifwatchd has been
> designed.

Not really, or it wouldn't need as much additional surrounding code to
do this.  ifwatchd was designed for a related but distinctly different
function (watching for things such as hotplugged PCMCIA interfaces,
PPPoE interfaces, etc).

> If you need to wait for state to say all interfaces are ready then
> you also need a system to say that interfaces have become non ready -
> state can and will change.

For the use case that prompted this, I do not need any such system.

The use case is /etc/rc.conf setting up (in the specific case at hand)
bridge0, fxp0, and tap0.  As soon as fxp0 and bridge0 both exist, I
want to run brconfig bridge0 add fxp0; as soon as tap0 and bridge0 both
exist, I want to run brconfig bridge0 add tap0.

Historically, I've dealt with this by careful ordering of
$net_interfaces, with comments in rc.conf to keep future edits from
breaking that ordering.

I could have added an ifsetup_post_bridge0 that checks for fxp0 and
tap0, an ifsetup_post_fxp0 that checks for bridge0, and an
ifsetup_post_tap0 that checks for bridge0.  But this (a) would be
brittle if I forget to set up one of them and it happens to work at the
moment because of the other one with the current interface ordering and
(b) means duplicating the "do this when ..." code, or adding additional
jiggery-pokery to somehow make both of them refer to something common.

Instead, I wanted to add something like (to use ifconfig -W)

ifsetup_post_bridge0="((ifconfig -W bridge0 tap0; brconfig bridge0 add tap0) &); ((ifconfig -W bridge0 fxp0; brconfig bridge0 add fxp0) &)"

and have everything Just Work.  (In practice it wouldn't even need
bridge0 on the ifconfig -W lines, because it's in ifsetup_post_bridge0
and thus never runs before bridge0 exists.  But I would do it anyway as
future-proofing in case I move them to tap0 and fxp0 instead.)  All the
interfaces in question are long-lived enough that dealing with them
going away is well outside the "stuff I care about" perimeter.

> If you're waiting for an interface to appear, that implies it's
> hotplugged somehow.  If it can be hotplugged, it can easily be
> unplugged.

You are making incorrect assumptions about my use case.  See above.

Yes, tap0 and bridge0 could be destroyed.  I don't care about my setup
working in that use case any more than I care about keeping it working
if root does "dd if=/dev/zero of=/dev/mem".

> The fact that you mention state storage implies that the problem you
> are trying to solve is fairly complex (or the state is) - can you
> share this with us?

You don't need state storage in the "one process which waits and exits
when it's done" case (well, except within the address space of that
process - I'm talking about external-to-processes storage).  You need
state storage in the "one long-running process which handles multiple
ongoing wait operations" case - or at least it seems to me you do; if
you can come up with a way to make it work without state storage, more
power to you.

>> It appears your stance is that that's the right answer.  If - if! -
>> that is NetBSD's stance as well, I will take that as a lack of
>> interest in adding the capability to ifconfig and will leave my own
>> tree at ifconfig -W.
> The last time I checked, I'm not Mr NetBSD.

No.  Hence the "- if! -", because I realized that if I wrote just "If
that is NetBSD's stance", it would have been easy to read as not a true
hypothetical but a "well if _that_'s what's going to happen..."
phrasing, which is not what I intended at all.

> But I also belive in doing the right thing, but I for one dont
> understand what the right thing is yet.

I'm not sure I do either.  It's possible I'm solving a special case
when a more general solution would be better - the good being the enemy
of the best.  But I'm also not fond of adding complexity to solve a
more general problem that nobody ever cares about in practice.  So,
until I see a need to generalize my desire, I'm disinclined to build
something more general.

Indeed, I could have just fallen back on careful ordering of
$net_interfaces.  But I've done that often enough for it to be irksome;
it's something I've solved with a "not good but (barely) good enough"
solution enough times to feel I have a moderately good handle on what a
righter solution would look like.

ifwatchd was a good suggestion for joerg@ to have made; indeed, I had
forgotten it existed when I wrote the code I did.  But ifwatchd was
designed to solve a different problem; the resulting solution, while
fine for that problem, strikes me as a rather poor fit to my use case.

If you want to argue that this operation should go into ifwatchd
instead of ifconfig, well, I might agree with you; I haven't thought
about it enough to have formed an opinion.  I'm not sure I like
starting ifwatchd as early as starting the network; this seems
especially likely to be problematic on systems where /usr isn't on /,
though I'm not sure whether this use case is special-case enough for
that to matter.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B