Re: Wait for interface existence?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Sorry for the late reply, I've been switching email host due to DKIM
> header issues from mailing lists.  Should be fixed now, but sadly I
> can't do anything about your email server still rejected emails from
> me after many years.

It does?  Your direct copy to me arrived fine.  Maybe you sent this one
through a different outgoing path than past attempts or some such.

>>> So *why* do you feel the need to shutdown ifwatchd. 
>> So it doesn't remain forever cluttering up the process table.
> It's hardly the biggest or most CPU consuming process, but OK.

Neither is ls, but would you want a process permanently lying around
every time you ran ls?

Okay, ls is commoner, but I still don't want even a few processes
sticking around forever (or until manually killed) after their jobs are
done.  (The "one process handles them all" version might be OK from
this perspective, but it's also the one requiring the most, and the
most complex, additional code in and around ifwatchd.)

>> 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).
> But this is exactly the functionality you are asking for in ifconfig?

Close.  Both tasks are built upon "watch for interfaces"; the
differences lie in the details, such as what happens when an interface
of interest does put in an appearance.

As I remarked upthread, ifwatchd might have been a better program to
add this functionality to.  If someone does that in modern NetBSD, I
might change my system to match, but doing that would probably be
relatively low priority for me.  I don't currently know how much code
it would add to ifwatchd; I haven't looked at its internals at all.

>> 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 [...]

> OK, so this is just an overly complex solution to the simple fact you
> sometimes struggle to setup rc.conf for bridging.

If that's how you choose to see it, sure.  I consider a hundred lines
of code in ifconfig a relatively cheap price for the benefit of
robustness of rc.conf against reordering of interfaces.  (For that
matter, is it documented - and committed to - that $net_interfaces is
processed in order?  If not, depending on it is a Bad Idea.)

> Common sense tells me that we should create the virtual interfaces
> before adding them to the bridge so they should appear first, but heh
> ho.

That's what I used to do.  It feels unpleasantly fragile, though.

> Why not just script it entirely in /etc/ifconfig.fxp0?

Well, in ifsetup_post_fxp0 - I don't use per-interface files,
preferring to keep my network configuration in one file.  Yes, I could,
in this case.  If I wanted two real interfaces involved, that wouldn't
work.  I also prefer to not hide interface A's setup inside interface
B's setup.

There's more than one way to skin this particular cat, yes.  This is
hardly the only task that's true of, and I don't consider it an
argument against this ifconfig flag.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B