1394 SPB-2 Drives
Mark --
Quoted 7 lines
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...
Yes, I see that stack handling all such notifications because, as you noted, 1394 is more USB-like than SCSI-like when it comes to hotplugging. More different kinds of device; isochrony; and so on. Very much in particular, disks aren't the "typical 1394" device (I think of video :-).
Oliver --
Quoted 3 lines
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.
I don't know where that came from, but notice I never said anything about such stuff. In fact, neither does the firewire code I glanced at -- Initiator/Target is the terminology.
Quoted 2 lines
At present hotplugging in this driver sucks and will continue to do so until the scsi subsystem is extended.
I didn't see any hooks to scsi in drivers/ieee1394, so this also seems unrelated to the basic hotplug checklist I gave. Perhaps you're referring to a specific driver that's not in that directory of generic 1394 code?
Quoted 3 lines
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.
Once the bus code has hotplugged a disk-style device so that a block device driver is hooked in, then yes -- then you need partition info.
But that's pretty late in the game, and can't apply to devices like video cameras or a VCR.
- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 7 lines
Quoted 3 lines
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.
I don't know where that came from, but notice I never said anything about such stuff. In fact, neither does the firewire code I glanced at -- Initiator/Target is the terminology.
That's from usb-storage. It's the only currently working way to get a device that uses the scsi command set to support hotplugging.
Quoted 8 lines
Quoted 3 lines
At present hotplugging in this driver sucks and will continue to do so until the scsi subsystem is extended.
I didn't see any hooks to scsi in
drivers/ieee1394, so this also seems unrelated to the basic hotplug checklist I gave. Perhaps you're referring to a specific driver that's not in that directory of generic 1394 code?
I was referring to the SPB-2 subclass of ieee1394 devices which like usb-storage use the scsi command set. The driver for them indeed is not part of the standard kernel. These disks (and scanners) are the hardest case. If they work everything works in terms of hotplugging.
Quoted 9 lines
Quoted 3 lines
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.
Once the bus code has hotplugged a disk-style device so that a block device driver is hooked in, then yes -- then you need partition info.
But that's pretty late in the game, and can't apply to devices like video cameras or a VCR.
Exactly. Hotplugging for those already worksaccording to the statius page of 1394. Disks are the hard part.
And while we are discussing ieee1394, how does Linux support use of that bus as a LAN ?
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 9 lines
Quoted 3 lines
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.
Once the bus code has hotplugged a disk-style device so that a block device driver is hooked in, then yes -- then you need partition info.
But that's pretty late in the game, and can't apply to devices like video cameras or a VCR.
Exactly. Hotplugging for those already worksaccording to the statius page of
1394. Disks are the hard part.
[MWK] Careful here. I think this means 'hot plugging' as defined by the folks working on 1394, not 'hotplugging' as defined by the folks working here. 1394 devices can be added or removed from the 1394 bus and the 1394 driver stack sees it. However, I think that all this stack does so far is support an interface library above it for small apps to talk to the hardware. [PLEASE REMEMBER, I'M NOT A SOFTWARE GUY!!!]
And while we are discussing ieee1394, how does Linux support use of that bus
as a LAN ?
[MWK] There is the beginnings of a TCP/IP Over 1394 driver that works to some degree, although I have not used it. Last I heard it had to be installed
as a module, which I personally rebel against being that I'm a newbie to Linux and don't know how to do it reliably and automatically! I am quite interested in this as I have a similar network up and running using Win ME and would like to replace it one of these days...
Regards
Oliver
_______________________________________________
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