RE: netdevice problem - 1394 SPB-2 Drives

[Mark Knecht <mknecht@controlnet.com>]

Hi,
   I'm a total 'lurker' here, but am involved on the hardware side with the
work going on with Linux-1394 support. 

   How do you guys seeing 1394 disk drives fitting into the hot-plug mix?
The performance is much higher than USB, similar maybe to SCSI, but as of
right now I do not believe that it will be possible to boot from a 1394
drive, so the file system problems may not be a bad as SCSI.

   We do have the beginnings of drive support there. Folks are starting to
use 1394 hard disks, as well as CDs and DVDs.

Mark

-----Original Message-----
From: David Brownell [mailto:david-b@pacbell.net]
Sent: Thursday, January 18, 2001 9:04 AM
To: Andrew Morton; linux-hotplug-devel@lists.sourceforge.net
Subject: Re: netdevice problem


> 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

_______________________________________________
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