Am Dienstag, 21. Januar 2003 12:57 schrieb Douglas Gilbert:
> Oliver Neukum wrote:
> > <snip/>
> >
> > I simply don't trust the SCSI layer. I've had to much trouble with it
> > already.
>
> Hopefully we have some better building blocks and
> clearer code in 2.5 to look at this problem in the SCSI
> subsystem again.
I surely hope so. Let's discuss it.
> The first thing a LLDD should do when it _knows_ the device
> is gone is set scsi_device::online=0 ** which should stop all
The SCSI should export functions to do that and to do it to all
a host's devices.
> new commands being queued. Now if scsi_device::access_count
> is zero then we have no problems *** and most of the code
> we need is in place in latter half of scsi_remove_single_device().
Yes. And scsi_device_get() should check for a device having been
unplugged.
> The hard case is when scsi_device::access_count>0 which means
> open()s or mounts are active on that device. So sd, sr, st, osst
> and/or sg know about a file descriptor (or the block equivalent)
What is the block equivalent?
> that is associated with that "departed" scsi_device instance. I
> have code in sg in lk 2.4 to partially handle the case when
> detach is called on a device for which sg holds an open fd.
> Sg can handle this because it shadows scsi_device and
> scsi_cmnd instances. The next time an app tries to access
> that fd it gets a ENODEV (even sends out a SIGIO/POLL_HUP for
> advanced apps). I suspect life would not be so simple for sd
> and sr due to their close binding with the block subsystem.
> Another approach to this problem is to keep the scsi_device
> instances for departed devices around until the access_count
> drops to zero. One silly idea I had was to change the seldom
That looks like a workable approach.
> used channel number to 1024 (or the next free number above that)
> to maintain the uniqueness of the host/channel/id/lun tuple ****
> and keep the original tuple available for the re-appearance
> of the departed device.
>
> Compounding the hard case is when commands are queued. Can
> these simply be ENODEV-ed back to the apps that own them?
> If so, that may help the access_count drop to zero facilitating
> scsi_device removal.
The LLDD can certainly return an error for the commands already queued.
> Question: do we need to worry about hot unplugging of hosts?
Yes, definitely yes. A USB storage device is a virtual host, since
scsi ids would otherwise collide. Besides, PCMCIA SCSI host are
not exactly brandnew either.
> ** Since 'online' already has a usage (i.e. error recovery
> couldn't resurrect this device) perhaps something stronger
> like 'departed' is needed as well (or some sysfs mechanism).
> BTW sg sidesteps 'online' when a file descriptor is opened
> non-blocking.
Good idea.
So a disconnection would look like this:
scsi_set_offline_host(...);
synchronize_kernel();
error_queied_commands(...);
scsi_remove_host();
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Scholarships for Techies!
Can't afford IT training? All 2003 ictp students receive scholarships.
Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
www.ictp.com/training/sourceforge.asp
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
