netdevice problem - 1394 SPB-2 Drives
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:[email protected]]
Sent: Thursday, January 18, 2001 9:04 AM
To: Andrew Morton; [email protected]
Subject: Re: netdevice problem
Quoted 5 lines
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.
Quoted 11 lines
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/hotplugN 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?)
Quoted 3 lines
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!
Quoted 1 line
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?
Quoted 10 lines
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.
Quoted 4 lines
4: Rework
call_usermodehelperfor 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.
Quoted 6 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · 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.
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
Signature · 6 lines
greg@(kroah|wirex).com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Thursday, January 18, 2001 10:20 AM
To: Mark Knecht
Cc: [email protected]
Subject: Re: netdevice problem - 1394 SPB-2 Drives
Quoted 2 lines · Mark Knecht
Hi,
I'm a total 'lurker' here, but am involved on the hardware side with
the
Quoted 6 lines
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
Signature · 6 lines
greg@(kroah|wirex).com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines · Oliver Neukum
Quoted 5 lines
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
Signature · 6 lines
greg@(kroah|wirex).com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line
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 ... ;-)
Quoted 1 line
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!
Quoted 6 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · David Brownell
Quoted 1 line
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
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:[email protected]]
Sent: Thursday, January 18, 2001 3:18 PM
To: David Brownell; Mark Knecht; [email protected]
Subject: Re: netdevice problem - 1394 SPB-2 Drives
Quoted 1 line · David Brownell
Quoted 1 line
How do you guys seeing 1394 disk drives fitting into the hot-plug
mix?
Quoted 5 lines
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
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel