Re: hotplug TTD

[David Brownell <david-b@pacbell.net>]

> From: Andrew Morton <andrewm@uow.edu.au>
> Sent: Wednesday, January 10, 2001 2:58 AM
>
> David Brownell wrote:
> > 
> > Second, there are various types of related functionality to be
> > developed.  Addressing the "can't hotplug during boot" issue
> > (something kudzu-like to scan /proc/bus/{usb,pci}/*/* and create
> > hotplug events).  Some sort of generic analogue to "cardctl eject"
> > would be good.  And as Miles noted, "pcmcia_cs" is a degenerate
> > case of (generic) hotplug ...
> 
> mm..  For PCI isn't it simply a matter of parsing /proc/bus/pci/*/*
> (or lspci output) to determine all the devices, then synthesising
> hotplug events for them?

Yes.

Though when I started to think about how to do that stuff robustly, I
began to wish a kernel "module" didn't stop being a visible component
when it gets statically linked.  There's a rather arbitrary line between
static linking (build tools) and dynamic linking (modutils).  Hotplugging
a device shouldn't need to care so much how the driver module is linked.


> Now, there are a number of bells-n-whistles which could be added
> here.  For example, people get irritated when they put their network
> cards into different slots and eth0 and eth1 get swapped around. We
> could fix this with some constraints, or a manual override before
> the automatic hotplug synthesis.

David Hinds at one point spoke in favor of having more info passed
to the network hotplug events than just the interface name.  That's
critical for statically configured hardware (servers); dynamically
configured ones (pure DHCP clients, say) should not care.

It's a generic problem with the notion of automagically assigning
"user meaningful names" to hardware.  Happens all the time when
USB devices show up ... two card readers, two cameras, etc have
exactly analagous problems.  And it's not a problem "devfs" is
able to handle, near as I can tell.


> This is just one requirement - there are surely many others.  'fraid
> I haven't started to get my head around it yet.

Me either.  Hence my "..." above ... ;-)


> > There's also device/driver specific initialization that we should
> > understand better.  We know how to ensure that a USB controller
> > (on any PCI bus) is cleanly initted.  I don't think we know how
> > to do that for a disk drive (start with SCSI and generalize) or
> > printer.
> 
> err, yes.   Plus if you run `/sbin/hotplug pci' five times
> back-to-back for five devices, you'll cause a great storm
> of initialisation activity, concurrent execution of
> modprobe and all sorts of things.  Kernels will explode,
> I promise :) 

Exploding penguin-shaped TV set-top boxes ... the holy grail
of kernel development?  Clearly a sign that we need Python
developers involved ... ;-)

- Dave




_______________________________________________
Linux-hotplug-devel mailing list
Linux-hotplug-devel@lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel