netdevice problem

netdevice problem

[Andrew Morton]

As far as I know, the "vision" is that the hotplug
architecture can be used at boot time.  We identify
all the ISA/PCI/whatever devices and create hotplug
insertion events for them, and just let the hotplug
magic happen.

There are several ways of doing this, most notably:

a) Buffer the results of the bootup PCI scan and
   spit out hotplug events after filesystems have
   been mounted, etc.

b) Scan the buses from initscripts, synthesise hotplug
   events from userspace.

Both approaches are broken, because we'll end up
running /sbin/hotplug N times concurrently.  The
assignment of eth0, eth1, eth2, etc will be totally
random and people will hate us.

The fixes appear to be:

1: Funky hard-wired delay in the hotplug synthesiser.  (cs89x0
   will require five seconds, please...)

2: Funky userland locking which blocks each hotplug synthesis
   until the previous one has completed its `ifconfig up',
   if it indeed did it.  This is crap.

3: Stick with modutils.conf to drive the bootup process,
   switch to hotplug scripts for post-boot insert/remove.
   This is a sad mix.

4: Rework call_usermodehelper for synchronous (or completion
   callback) semantics.  So the pci layer's callout doesn't
   return until both 'hotplug pci' and its child, 
   'hotplug net' have terminated.

Option 4 is of course the patch-which-didn't-make-it.  I haven't
resubmitted because the jury is still out on whether it's
still needed.  If the current setup can be reasonably used
from userspace then let's not hassle Linus.

But I now feel it's needed.  Any clever ideas out there?

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

Re: netdevice problem

[Adam J. Richter]

At boot time, you should run something like this (this is hand
written because I do not want to wade through the other cruft
currently in our boot scripts):

	# We include "off" in the list to avoid a shell syntax error
	# in case the other modules turn out to be an empty list.
	modprobe -s -k isa-pnp
	for module in off $(isapnpmodules) $(pcimodules) ; do
		modprobe -s -k $module
	done

	( modprobe i82365 || modprobe tcic ) && cardmgr -o

	# The isapnpmodules and pcimodules loop must be run before
	# parportmodules is evaluated because they may load parallel
	# port controllers.  Perhaps this is also true of PCMCIA.
	for module in off $(parportmodules) ; do
		modprobe -s -k $module
	done

	# USB initialization occurs as a result of USB host controllers
	# being loaded (usually from pcimodules), and the host controller
	# modules generating hot plug events for the devices that are
	# already attached.  Other devices
	# This is all synchronous becuase, in the kernel, while
	# usermode_helper is not synchronous, request_module is.
	# So, we always load the modules in the same order at each
	# boot (given the same hardware).

	# We did the initialization in order of least likely to do hot
	# plugging to most likely in order to reduce the likelihood of
	# gaps in device numbering as devices are added and removed
	# (basically as a user interface issue, not for any other reason).

Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 104
adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
+1 408 261-6630         | g g d r a s i l   United States of America
fax +1 408 261-6631      "Free Software For The Rest Of Us."

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

Re: netdevice problem

[David Brownell]

> As far as I know, the "vision" is that the hotplug
> architecture can be used at boot time.  We identify
> all the ISA/PCI/whatever devices and create hotplug
> insertion events for them, and just let the hotplug
> magic happen.

Nobody's presented reasons why that shouldn't be the
case.  I can wonder about the risks of duplicated
events, but we don't have that problem yet ... and
hotplug event handlers need to handle such cases.


> There are several ways of doing this, most notably:
> 
> a) Buffer the results of the bootup PCI scan and
>    spit out hotplug events after filesystems have
>    been mounted, etc.
> 
> b) Scan the buses from initscripts, synthesise hotplug
>    events from userspace.
> 
> Both approaches are broken, because we'll end up
> running /sbin/hotplug N times concurrently.

I'm not sure I see why (b) should have that flaw, but
queuing up hotplug notifications in the kernel might
well have problem (a) unless there's a throttling
mechanism like permitting only one /sbin/hotplug
call at a time.

I've been assuming (b) in any case, but will not
have time soon to write an /etc/hotplug/pci.rc script
to do that.  (Volunteers?)


>      The
> assignment of eth0, eth1, eth2, etc will be totally
> random and people will hate us.

If the kernel device scanning order is defined, then it
can be followed in userland.  If the kernel doesn't define
that order ... people should hate the kernel instead!


> The fixes appear to be:

You mean fixes to the "everything collides" problem, yes?  The
one I've seen to completely wedge a Linux box, so that I'm
very glad to have SysRq enabled?


> 1: Funky hard-wired delay in the hotplug synthesiser.  (cs89x0
>    will require five seconds, please...)
>
> 2: Funky userland locking which blocks each hotplug synthesis
>    until the previous one has completed its `ifconfig up',
>    if it indeed did it.  This is crap.
>
> 3: Stick with modutils.conf to drive the bootup process,
>    switch to hotplug scripts for post-boot insert/remove.
>    This is a sad mix.

All of those seem like we'd be better without them.  Usermode
workarounds, not real fixes.


> 4: Rework call_usermodehelper for synchronous (or completion
>    callback) semantics.  So the pci layer's callout doesn't
>    return until both 'hotplug pci' and its child, 
>    'hotplug net' have terminated.

Or the USB layer's ... this closely relates to one of the remaining
issues on my own "Hotplug TTD" list (async change issues)

http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m—906053523984&w=2

and curiously enough, other than integrating Keith's usb_device_id
patch and writing code to emulate hotplug for boot time events,
this seems like one of the main remaining issues.


> Option 4 is of course the patch-which-didn't-make-it.  I haven't
> resubmitted because the jury is still out on whether it's
> still needed.  If the current setup can be reasonably used
> from userspace then let's not hassle Linus.
> 
> But I now feel it's needed.  Any clever ideas out there?

I've liked it too, and it's been on my list (see above :-).
Having given up on chasing a driver problem for a while, I'll
get back to this one soon.

Perhaps you should post your patch to this list, so that more
folk can see it and evaluate your option 4?  Or even help out
with the testing/development.  It seems to me this is the main
unresolved "hotplug infrastructure" problem just now; most of
the other stuff should be ready to go, given Keith's patch.

- Dave



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