RE: netdevice problem - 1394 SPB-2 Drives

RE: netdevice problem - 1394 SPB-2 Drives

[Mark Knecht]

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

Re: netdevice problem - 1394 SPB-2 Drives

[Greg KH]

On Thu, Jan 18, 2001 at 10:03:18AM -0800, Mark Knecht wrote:
> 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.

I'm starting to experiment with booting a Linux install from a USB CDROM
drive, and look like I have things almost working.  But the biggest
problem (and one that you will probably have) is that you need BIOS
support to boot from the device.

Do any BIOSs support bootable 1394 devices, like hard drives?

If not, I don't think that it will ever work, but would be glad to be
proven wrong.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com

_______________________________________________
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 - 1394 SPB-2 Drives

[Mark Knecht]

Greg,
   To the best of my knowledge, there is no INT13 type support for any 1394
controller out there today. None of the add in cards that I have seen have
any BIOS extensions in ROM on them, so I would presume that the only
machines that might support booting would be machines that have 1394 built
into them, and there are precious few of those. (Sony, NEC, ...) I suppose
that someone like Adaptec, that has built combo SCSI/1394 cards in the past
would be a candidate for something like this, but I believe they exited the
1394 business when OHCI came along. (Maybe they'll come back!!!)

   To further complicate 1394, the drives are SPB-2 drives, and while I'm no
expert on this, there are a lot of things in SPB-2 that require a system to
essentially log into the drive before they use it. All of this is expensive
to put in system BIOS when there's no major user for it, so I don't think
we'll find it there either...

   I was interested the other day when someone made a comment about it being
a bad idea to hot plug your swap space, or something to that effect. Losing
important parts of the file system are a really bad idea, I suppose... ;-)
However, 1394 peripherals are emerging and I'd love to see them get some
real system support one of these days....

Just learning,
Mark

-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Thursday, January 18, 2001 10:20 AM
To: Mark Knecht
Cc: linux-hotplug-devel@lists.sourceforge.net
Subject: Re: netdevice problem - 1394 SPB-2 Drives


On Thu, Jan 18, 2001 at 10:03:18AM -0800, Mark Knecht wrote:
> 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.

I'm starting to experiment with booting a Linux install from a USB CDROM
drive, and look like I have things almost working.  But the biggest
problem (and one that you will probably have) is that you need BIOS
support to boot from the device.

Do any BIOSs support bootable 1394 devices, like hard drives?

If not, I don't think that it will ever work, but would be glad to be
proven wrong.

thanks,

greg k-h

-- 
greg@(kroah|wirex).com

_______________________________________________
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 - 1394 SPB-2 Drives

[Greg KH]

On Thu, Jan 18, 2001 at 07:35:25PM +0100, Oliver Neukum wrote:
> 
> > Do any BIOSs support bootable 1394 devices, like hard drives?
> >
> > If not, I don't think that it will ever work, but would be glad to be
> > proven wrong.
> 
> Think broader. A Mac'll probably able to do it. Linux runs on PPC,too.

Doh!
You are so right.  Never mind...

greg k-h

-- 
greg@(kroah|wirex).com

_______________________________________________
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 - 1394 SPB-2 Drives

[David Brownell]

>    How do you guys seeing 1394 disk drives fitting into the hot-plug mix?

Right on top of basic 1394 hotplug support!

The hotplug bus support for PCI and USB is pretty similar ... how well
do these map to the ieee1394 subsystem?

    - Drivers that are already linked into the kernel need to be
      dealing with binding to devices as they're plugged in, and 
      cleanly unbinding as they're unplugged.  PCI and USB seem
      to have reasonable probe() models to borrow from.  USB has
      a thread (khubd) to enumerate new devices, Cardbus has a
      similar one (watcher).

    - MODULE_DEVICE_TABLE support should tie into the driver binding,
      so that it's exported (by *_device_id entries) by modutils so
      that usermode drivers can connect.  "modules.ieee1394map" ?

    - Some invocation of the hotplug helper (/sbin/hotplug by default)
      on device add/remove events, so that the right driver module can
      be loaded (if needed) and configured (ditto).

    - There should be a /proc/bus/... entry for the 1394 busses, which
      lets usermode code at least find out about the devices that are
      present.  (Some info gets passed to /sbin/hotplug; likely not
      everything that every device needs for modprobe/configure.)

Then on top of that core framework, some higher level component ought
to report events appropriate to each driver.  

That's where I'd hope that disks on SCSI, IEEE1394, USB, and so on would
just be able to rely on what, say, the block device system does.  Which
might not involve a call to /sbin/hotplug ... some folk want devfsd to
handle such stuff.   (Me, I'd rather not have daemons around.)

It could be fun to see v4L hotplugging pop up a video window when you
plug in your video camera on IEEE1394 or USB ... ;-)


> The performance is much higher than USB, similar maybe to SCSI,

Faster than current USB, yes.  USB 2.0 hardware is starting to become
available though; 480 Mbps (60 MByte/sec) looks to get interesting.
Yes, the upcoming generation of Firewire will be even faster!


>     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.

If the Firewire drivers are statically linked, I'd hope that it would be
possible to boot from such a disk drive.  Given boot rom support, that is.

The hotplug boot time issue I know is how devices connected to a hotplug
bus at boot time get configured, when the bus driver is statically linked
and initted.  Right now it's best if you plug them in after hotplug
processing starts in userland; it doesn't look at what's there already.

- 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

Re: netdevice problem - 1394 SPB-2 Drives

[Oliver Neukum]

On Thursday 18 January 2001 22:47, David Brownell wrote:
> >    How do you guys seeing 1394 disk drives fitting into the hot-plug mix?
>
> Right on top of basic 1394 hotplug support!
>
> The hotplug bus support for PCI and USB is pretty similar ... how well
> do these map to the ieee1394 subsystem?

That's not the issue in this case. SCSI is the problem.
I've looked at that driver. It needs to deal with device addition/removal.

As there are a lot of device on a firewire bus, it probably can't use the 
pseudo host controller hack. And shouldn't - it's a hack, which is 
unfortunately necessary for usb.

At present hotplugging in this driver sucks and will continue to
do so until the scsi subsystem is extended.

Even then for configuration there's a need to further support.
The raw news about a device is of little use. You need the information about 
partitions and other things.

	Regards
		Oliver

_______________________________________________
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 - 1394 SPB-2 Drives

[Mark Knecht]

Hi,
   First, I'm not the guy to make any decisions about how this might get
done in the 1394 driver stack. I'm a hardware guy and system oriented.
However, that said, the 1394 usage model is more similar to USB, in general,
than it is to SCSI. There are lots of 1394 devices. They serve lots of
purposes. And hot plugging is a basic part of the way 1394 works, at both
the hardware and software levels.

   Additionally, there are 1394 bridges coming which will link together many
1394 buses, and there are going to be both local and distant discovery
issues involved when devices are added and removed. I presume that
_eventually_ we'll want to be able to extend the hot plugging concepts to
find 1394 disk drives that are located a couple of miles away across some
1394b interface. But that's in the future.

   So, I think part of the issue here is that the 1394 stack is going to
have a fairly low level part that is handling the hardware part of notifying
the system that something has happened. Above that the 1394 stack will
probably need to let the hot plugging system know about certain device
changes, but possibly not about all devices. Do you see this software being
responsible when I plug in 1394 printers, cameras, speakers, home theatre
equipment, as well as disk drives? I'm not clear...

   Thanks for the opportunity to wave the flag for 1394!

Mark

-----Original Message-----
From: Oliver Neukum [mailto:Oliver.Neukum@lrz.uni-muenchen.de]
Sent: Thursday, January 18, 2001 3:18 PM
To: David Brownell; Mark Knecht;
linux-hotplug-devel@lists.sourceforge.net
Subject: Re: netdevice problem - 1394 SPB-2 Drives


On Thursday 18 January 2001 22:47, David Brownell wrote:
> >    How do you guys seeing 1394 disk drives fitting into the hot-plug
mix?
>
> Right on top of basic 1394 hotplug support!
>
> The hotplug bus support for PCI and USB is pretty similar ... how well
> do these map to the ieee1394 subsystem?

That's not the issue in this case. SCSI is the problem.
I've looked at that driver. It needs to deal with device addition/removal.

As there are a lot of device on a firewire bus, it probably can't use the 
pseudo host controller hack. And shouldn't - it's a hack, which is 
unfortunately necessary for usb.

At present hotplugging in this driver sucks and will continue to
do so until the scsi subsystem is extended.

Even then for configuration there's a need to further support.
The raw news about a device is of little use. You need the information about

partitions and other things.

	Regards
		Oliver

_______________________________________________
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