Re: ifconfig stopped loading driver

From: Kevin Oberman <oberman_at_es.net>
Date: Fri, 23 Mar 2007 14:35:39 -0700
> Date: Fri, 23 Mar 2007 19:33:37 +0300
> From: Yar Tikhiy <yar_at_comp.chem.msu.su>
> 
> On Fri, Mar 23, 2007 at 09:06:10AM -0700, Kevin Oberman wrote:
> > > Date: Fri, 23 Mar 2007 08:52:27 -0700
> > > From: Sam Leffler <sam_at_errno.com>
> > > 
> > > Yar Tikhiy wrote:
> > > > On Thu, Mar 22, 2007 at 10:31:44AM -0700, Kevin Oberman wrote:
> > > >>> Date: Thu, 22 Mar 2007 09:15:22 -0700
> > > >>> From: "Kip Macy" <kip.macy_at_gmail.com>
> > > >>>
> > > >>> On 3/22/07, Kevin Oberman <oberman_at_es.net> wrote:
> > > >>>> For a long time under V6 and current (and probably V5), if I issued an
> > > >>>> ifconfig for my Atheros card, the driver (along with the HAL and rate
> > > >>>> modules) would auto-load and my card would be found.
> > > >>>>
> > > >>>> Starting with my March 19 build, this no longer happens. I need to boot
> > > >>>> single-user and manually load the module if I will need it. I don't want
> > > >>>> the card to start by default since I don't want the radio on when I am
> > > >>>> flying.
> > > >>>>
> > > >>>> Was this a deliberate change or did something break? It is a real pain.
> > > >> O.K. It is clearly a deliberate change, although I am not sure the
> > > >> effect is what was intended.
> > > >>
> > > >> The call to ifmaybeload(ifname) was moved inside of the if for a
> > > >> "create" which applies to pseudo-devices, but not "real" interfaces. As
> > > >> a result, the driver never gets loaded. I read the commit message, but I
> > > >> don't think that this is the right way to fix the problem
> > > >> described. (I'm not sure, what a better approach might be, though.)
> > > >>
> > > >> This breaks behavior that goes back over 7 years, having appeared in
> > > >> the first release of V4. I can work around it, but it's going to be a
> > > >> big surprise to many and it is sure a pain in the neck to me.
> > > > 
> > > > I readily admit that my change provoked your trouble.  When committing
> > > > it, I took into account only cloned interfaces, but not hardware
> > > > ones, perhaps because I had never used modules for hardware interfaces.
> > > > 
> > > > Nevertheless, I still think that the practice of loading the module
> > > > on any ifconfig command is poor in spite of its age.  It can be
> > > > worked around only by dirty hacks.  One of them is an ifconfig
> > > > option not to load the module for devd scripts to use it when
> > > > shutting down the interface.  Another one is to load the module
> > > > only on "positive" ifconfig commands, such as "up" and "alias"
> > > > (incl.  the first address,) but not on "negative" ones, e.g., "down"
> > > > and "-alias" -- but what to do with "ifconfig -alias up" then?
> > > > 
> > > > Perhaps it's time to have "ifconfig foo0 load" along with "ifconfig
> > > > bar0 create" to allow loading the module explicitly.  People even
> > > > won't have to specify "load" in their rc.conf files as rc.d can add
> > > > it for them when, and only when, the interface is started.
> > > > 
> > > > Comments?
> > > 
> > > I'm not a big fan of auto-loading the module either but it does change
> > > existing practice.  I've also considered having ifconfig auto-load the
> > > wlan_<crypto> modules when setting a crypto key so perhaps the best
> > > compromise is to leave auto-loading enabled by default and add an option
> > > to suppress it.
> > 
> > I have no issue with adding "ifconfig foo0 load". It is, at least, very
> > convenient to have ifconfig load the modules.
> > 
> > On my laptop I use this to auto-config for my location. I could just let
> > the loader do it, but I would always need to remember to comment it out
> > before booting when I am flying. Until/unless an "inflight" option is
> > available, this is fairly important.
> > 
> > (Actually, I can't load it at boot time due to a bug that disables my
> > mouse if I have the loader load a driver. I hope to have some time to
> > track this down some day.)
> > 
> > Now, if I need wireless support, I must "boot -s", "kldload ip_ath", and
> > "exit". (Or I can edit ifconfig.c to move the call.) I can probably hack
> > my rc scripts to get around this, too, but either reverting or adding a
> > "load" command would be cleaner (and less of a POLA issue).
> 
> By the way, did you try to kldload ip_ath from multiuser mode and
> let devd do the job of bringing the newborn interface up?  And how
> did you choose between the locations when ifconfig had its old
> semantics?

I have loaded if_ath in multiuser mode, but by then it is really too
late for the automatic localization. I fall through to my default, I
have no idea where I am, configuration. That's why I load it in
single-user mode.

I use Tobias Roth's profile.sh which runs right after root is mounted
r/w. It does a quick configuration of of each interface as per
rc.conf.local in a union-mounted per-location /etc and checks using dhcp
or ping for a location. If it finds a match, it leaves the
site-specific /etc mounted and continues the startup using the rc.conf,
rc.conf.local and any other files (such as sysctl.conf resolve.conf and
so on.

In the past, when it hit the first location that used wireless, if_ath
was auto-loaded by the ifconfig, but I could deactivate profile and it
would never be loaded. It was also not loaded when I was at work.

> I'm asking that so I know more cases of using the auto-load feature.
> Thanks for your patience!

I suspect that there are few people using profile.sh, but I find it very
convenient and it works better than anything else I have come across.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman_at_es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Received on Fri Mar 23 2007 - 20:35:43 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:07 UTC