A compendium of questions and misc stuff concerning hotplug:
- Is everyone happy with call_usermodehelper() being asynchronous? It
_could_ be given a `synchronous' option, but that's a fair bit of
obfuscation and it does expose us to deadlocks if the caller has any
semaphores held.
- One person who definitely needs synchronous semantics is
drivers/net/hamradio/baycom_epp.c. The poor thing is currently doing
the kernel_thread()/waitpid() stuff itself. So there's a datum.
hmm.. It's running a usermode app with the rtnl lock held.
There's a counter-datum.
- The three USB netdevice drivers look a bit racey in the probe()
function. Some can be fixed inline, but it may be better to just
call dev_probe_lock()/dev_probe_unlock() in
usb_find_interface_driver(). That's if dev_probe_lock() makes its
way to kernel.org...
- On the unregister/removal path, the netdevice layer ensures that
the interface is removed from the kernel namespace prior to launching
`/sbin/hotplug net unregister eth0'.
This means that when handling netdevice unregistration
/sbin/hotplug cannot and must not attempt to do anything with eth0!
Generally it'll fail to find an interface with this name. If it does
find eth0, it'll be the wrong one due to a race.
- I don't think we can say that the kernel hotplug interface is
complete until we have real, working, tested userspace tools. David,
could you please summarise the state of play here? In particular,
what still needs to be done?
Andrew Morton wrote:
> - On the unregister/removal path, the netdevice layer ensures that
> the interface is removed from the kernel namespace prior to launching
> `/sbin/hotplug net unregister eth0'.
>
> This means that when handling netdevice unregistration
> /sbin/hotplug cannot and must not attempt to do anything with eth0!
> Generally it'll fail to find an interface with this name. If it does
> find eth0, it'll be the wrong one due to a race.
This is not a bug. 'unregister eth0' says to userspace "eth0 just
disappeared."
Read my previous messages on the subject: Add events like NETDEV_UP,
NETDEV_DOWN, and NETDEV_GOING_DOWN to netdev_event_names[] if you want
to call /sbin/hotplug for other netdev events.
Jeff
--
Jeff Garzik |
Building 1024 | These are not the J's you're lookin' for.
MandrakeSoft | It's an old Jedi mind trick.
Jeff Garzik wrote:
>
> Andrew Morton wrote:
> > - On the unregister/removal path, the netdevice layer ensures that
> > the interface is removed from the kernel namespace prior to launching
> > `/sbin/hotplug net unregister eth0'.
> >
> > This means that when handling netdevice unregistration
> > /sbin/hotplug cannot and must not attempt to do anything with eth0!
> > Generally it'll fail to find an interface with this name. If it does
> > find eth0, it'll be the wrong one due to a race.
>
> This is not a bug. 'unregister eth0' says to userspace "eth0 just
> disappeared."
Yes. I was simply pointing out a restriction which is placed upon
/sbin/hotplug in this situation.
> Read my previous messages on the subject: Add events like NETDEV_UP,
> NETDEV_DOWN, and NETDEV_GOING_DOWN to netdev_event_names[] if you want
> to call /sbin/hotplug for other netdev events.
erm.. I just deleted netdev_event_names[]. Without it, the way to do this
is to put
net_run_sbin_hotplug(dev, "netdev_going_down");
in the appropriate place.
I deleted it because of the 'Rebroadcast unregister notification' crap
in unregister_netdevice. If you want the netdev_event_names[] flexibility
back then we probably should kill the rebroadcast stuff.
But now that /sbin/hotplug is run asynchronously (Linus did it!) I
don't think this flexibility buys us much. You'll end up with
'/sbin/hotplug net netdev_going_down' and '/sbin/hotplug net netdev_down'
running simultaneously. What can they do?
In article <[email protected]> you wrote:
> A compendium of questions and misc stuff concerning hotplug:
> - Is everyone happy with call_usermodehelper() being asynchronous? It
> _could_ be given a `synchronous' option, but that's a fair bit of
> obfuscation and it does expose us to deadlocks if the caller has any
> semaphores held.
I am happy.
> - On the unregister/removal path, the netdevice layer ensures that
> the interface is removed from the kernel namespace prior to launching
> `/sbin/hotplug net unregister eth0'.
> This means that when handling netdevice unregistration
> /sbin/hotplug cannot and must not attempt to do anything with eth0!
> Generally it'll fail to find an interface with this name. If it does
> find eth0, it'll be the wrong one due to a race.
I always thought I should have to do "/sbin/ifdown eth0" here.
(Just as I do /sbin/ifup eth0 on register.)
> - I don't think we can say that the kernel hotplug interface is
> complete until we have real, working, tested userspace tools. David,
> could you please summarise the state of play here? In particular,
> what still needs to be done?
Well, for USB I would like to know which device major/minor entry a newly
plugged device is associated with.
Like if I insert a new USB camera, I want to easy find out it is char 81.1
(/dev/video1). Or if I plugin a USB storage device I want to easy find out
it is /dev/sda now.
This is currently very hard to do and it would be really nice to have
a solution for this.
Ciao, Marcus
> - I don't think we can say that the kernel hotplug interface is
> complete until we have real, working, tested userspace tools. David,
> could you please summarise the state of play here? In particular,
> what still needs to be done?
I think there's a lot of scope for more and better userspace tools, and we
have a great starting point with the latest 2.4 kernels. I think such tools
are pretty well _enabled_ now by the kernel. Some drivers don't yet help to
autoconfigure their devices; that'll come with time.
There's the "reference" /sbin/hotplug (CVS at linux-usb.sourceforge.net)
that makes a lot of devices usable immediately after you plug them in to
USB or CardBus. Real and working ... but more testing is always good.
(I got a bug report yesterday ... :-)
- Prefers to delegate to /etc/hotplug/$TYPE.agent if that's there,
otherwise it falls back to simple algorithms (next bullets).
- When new USB or PCI/Cardbus devices get added, driver modules
will get loaded (and maybe initialized). For 2.4 based systems,
drivers need a MODULE_DEVICE_TABLE for the driver to load.
- There's a convention that /etc/hotplug/$TYPE/$MODULE startup scripts
will get run. This hook lets you do things like running a program
to talk to your PDA (call from /etc/hotplug/usb/visor) or printer.
- When a new network device is registered, and "/sbin/ifup" is there,
it's invoked to try bringing up the device.
For 2.2.18 systems, USB hotplugging works (or so I'm told :-) using an older
approach to the problem solved by MODULE_DEVICE_TABLE in 2.4.x kernels.
One thing that needs to be done: figure out how to evolve the user mode
software moving forward. Right now that's one script, but I forsee smarter
hotplug agents complicating the picture. Life will be simpler if all distros
can share both core functionality (/sbin/hotplug) and ways to extend it (like
/etc/hotplug conventions). It'd happen more easily if we put "/sbin/hotplug"
into some official tool package (say, modutils) but that's not the only way.
As for system "hotplug" class functionality that's missing, "pcmcia_cs" is
a partial blueprint. Some of this needs kernel support:
- There's no Cardbus support for stuff like "cardctl eject", which
would call the PCI driver remove() method and let the driver shut
down cleanly while the device is still connected. I suspect a
solution like new ioctls on /proc/bus/pci files could solve that.
- Similarly with USB; though there's no tool like "cardctl" that
folk are no expecting to use. (If PCMCIA really needs tools to
cleanly shut down drivers, then it'd seem other hotplug busses
must too ... but nobody's suffering for this USB feature now.)
- Unless I missed a recent patch, only Cardbus (PCI) drivers get
hotplug notifications, not PCMCIA (ISA-ish) ones ... so there's
currently still a need for "cardmgr" if you're using PCMCIA cards.
(Getting rid of it isn't a 2.4.0 task; maybe not a 2.4.x task.)
- There's a feeling that IEEE 1394, SCSI, disk partitions, input,
and other sorts of Linux driver frameworks should move towards
autoconfiguration ("hotplug") ... surely not 2.4.0 issues!
There's some other stuff that seems less likely to need kernel changes:
- 'remove' events are ignored ... something else must unload modules,
like the "rmmod -as" cron job some systems run, or smarter agents
to handle the "remove" hotplug events.
- Devices that are recognized at boot before the root filesystem is
mounted are not going to get configured by /sbin/hotplug ...
something needs to run after root is mounted, scanning the busses
(/proc/bus/pci; and usbdevfs in /proc/bus/usb if it's configured
and mounted) and effectively faking hotplug events.
- For 2.4.x systems with "pcmcia_cs", the network hotplugging has
kicked in before the "pcmcia_cs" support doing the same stuff.
Something smart should IMHO remove that overlap, preferably by
making this something pcmcia_cs just doesn't do any more.
- More documentation will likely be needed.
All those additional usermode-only behaviors would seem to strongly benefit
from Linux standards for the relevant sysadmin and booting procedures, but
as I understand it they don't exist yet.
- Dave
Marcus Meissner writes:
>> - On the unregister/removal path, the netdevice layer ensures that
>> the interface is removed from the kernel namespace prior to launching
>> `/sbin/hotplug net unregister eth0'.
>>
>> This means that when handling netdevice unregistration
>> /sbin/hotplug cannot and must not attempt to do anything with eth0!
>> Generally it'll fail to find an interface with this name. If it does
>> find eth0, it'll be the wrong one due to a race.
>
> I always thought I should have to do "/sbin/ifdown eth0" here.
> (Just as I do /sbin/ifup eth0 on register.)
Yes, definitely. Otherwise, how can one replace the eth0 hardware
without messing up the network settings? This is supposed to be
hot plug and all... to me that means I can rip out one network
card and pop in another without breaking my ssh connections.
"Albert D. Cahalan" wrote:
>
> Marcus Meissner writes:
>
> >> - On the unregister/removal path, the netdevice layer ensures that
> >> the interface is removed from the kernel namespace prior to launching
> >> `/sbin/hotplug net unregister eth0'.
> >>
> >> This means that when handling netdevice unregistration
> >> /sbin/hotplug cannot and must not attempt to do anything with eth0!
> >> Generally it'll fail to find an interface with this name. If it does
> >> find eth0, it'll be the wrong one due to a race.
> >
> > I always thought I should have to do "/sbin/ifdown eth0" here.
> > (Just as I do /sbin/ifup eth0 on register.)
>
> Yes, definitely. Otherwise, how can one replace the eth0 hardware
> without messing up the network settings? This is supposed to be
> hot plug and all... to me that means I can rip out one network
> card and pop in another without breaking my ssh connections.
Let's see...
You pull the card (let's suppose it's Cardbus). That causes an
interrupt which eventually gets fed to the PCI layer's
pci_remove_device().
The PCI layer calls the netdevice's pci_driver.remove() method.
Typically, xxx_remove() calls unregister_netdevice().
unregister_netdevice() downs the interface, then removes the
netdevice from the kernel namespace and then runs
'/sbin/hotplug net unregister eth0' asynchronously.
When we return from unregister_netdevice() we can guarantee
that the driver's module refcount is zero if this was the
last matching device.
We then wind all the way back to the PCI layer, whizzing gaily
back through the driver whose module refcount is now zero. Sigh.
The PCI layer runs '/sbin/hotplug pci remove' asynchronously. The
driver can be unloaded.
So where in all of this can you read the interface's network
settings? Nowhere, I'm afraid. They're released in
unregister_netdevice().
Isn't this a userspace tool problem?
-
> > - I don't think we can say that the kernel hotplug interface is
> > complete until we have real, working, tested userspace tools. David,
> > could you please summarise the state of play here? In particular,
> > what still needs to be done?
>
> Well, for USB I would like to know which device major/minor entry a newly
> plugged device is associated with.
>
> Like if I insert a new USB camera, I want to easy find out it is char 81.1
> (/dev/video1). Or if I plugin a USB storage device I want to easy find out
> it is /dev/sda now.
How might that relate to devfs integration? It addresses similar
problems, and devfsd can call to userspace when such drivers (ones
that show up through major/minor device nodes) appear. True, some
folk who want to hotplug might want to not run devfs.
- Dave