1394 SBP-2 Drives
Hi,
Quoted 5 lines
Quoted 1 line
Quoted 1 line
As there are a lot of device on a firewire bus, it
probably can't use the
Quoted 3 lines
Quoted 2 lines
pseudo host controller hack. And shouldn't - it's a hack, which is unfortunately necessary for usb.
Quoted 7 lines
Quoted 3 lines
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.
The USB storage and IEEE-1394 SBP-2 drivers (as well as ide-scsi for that matter) serve as both scsi low-level drivers and high-level protocol drivers for their respective busses... this is done in order to leverage the scsi command set and higher-level block drivers and filesystems.
The primary difference between the two drivers (scsi-wise) is that the USB storage driver registers a new virtual SCSI host for each attached USB storage device, while the IEEE-1394 SBP-2 driver registers one SCSI host per IEEE-1394 bus, but maps each attached SBP-2 device as a virtual SCSI ID.
Quoted 5 lines
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.
The main issues currently for the SBP-2 driver (and SCSI) are how to trigger and deal with scsi device addition or removal, and how to get drives mounted and unmounted as appropriate. The work being done on /sbin/hotplug can certainly be leveraged, and the scsi folk are talking about hooks to allow for event driven addition/removal of devices (in the scsi mid-level code).
One additional issue to think about is "surprise" removal of storage devices (e.g. recovery and error handling after mounted drives with open files are
hot-unplugged). ;-)
Cheers,
--James
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines
The main issues currently for the SBP-2 driver (and SCSI) are how to trigger and deal with scsi device addition or removal, and how to get drives mounted and unmounted as appropriate. The work being done on
/sbin/hotplugcan certainly be leveraged, and the scsi folk are talking about hooks to allow for event driven addition/removal of devices (in the scsi mid-level code).
Mounting drives ? Are you refering to filesystem (on a medium) on the drives ?
If so, I am quite sure that this belongs to user space. Registering devices to the scsi layer should probably be done in kernel space.
Mounting in user space has its own set of problems which we fortunately need not discuss here. Another possible issue would be scripts changing /etc/fstab on hotplugging events. I am not sure I like that idea. It seems too risky to keep changing that file.
Regards
Oliver
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Oliver" = Oliver Neukum <[email protected]> writes:
Oliver> Another possible issue would be scripts changing /etc/fstab on Oliver> hotplugging events. I am not sure I like that idea. It seems Oliver> too risky to keep changing that file.
Agreed. A better solution to that particular issue may be to interface with autofs.
-JimC
Signature · 8 lines
James H. Cloos, Jr. <http://jhcloos.com/public_key> 1024D/ED7DAEA6 <[email protected]> E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6 _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines · Oliver Neukum
Mounting in user space has its own set of problems which we fortunately need not discuss here. Another possible issue would be scripts changing
/etc/fstabon hotplugging events. I am not sure I like that idea. It seems too risky to keep changing that file.
Well... I won't argue whether it is good or bad... but the PCMCIA subsystem already will automatically update /etc/fstab when new block devices are hot plugged, if desired.
-- Dave
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
http://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel