Re: Wait for interface existence?

[Roy Marples <roy%marples.name@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.

---- On Thu, 31 Aug 2023 03:19:10 +0100 Mouse  wrote ---

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

It's hardly the biggest or most CPU consuming process, but OK.
 
 >  
 > 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). 

But this is exactly the functionality you are asking for in ifconfig?

 >  
 > > 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. 
 
OK, so this is just an overly complex solution to the simple fact you sometimes struggle to setup rc.conf for bridging.
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.
Why not just script it entirely in /etc/ifconfig.fxp0? See ifconfig.if(5) for details.

$ cat /etc/ifconfig.fxp0
!ifconfig bridge0 create
!ifconfig tap0 create
!brconfig bridge0 add tap0
!brconfig bridge0 add $int
up
!ifconfig bridge0 up
 
Roy