Re: ifconfig stopped loading driver

From: Kevin Oberman <oberman_at_es.net>
Date: Fri, 23 Mar 2007 09:06:10 -0700
> 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).
-- 
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 - 15:18:17 UTC

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