Matthew Dharm wrote:
So, if I read this correctly, you're saying that the correct sequence is:
(1) get disconnect notification from USB
(2) Call scsi_set_device_offline() (must hold host lock for this)
(3) call scsi_done() for all command in queue (max: 1)
Right. LLDD does (2) and (3), though,
Mike Anderson wrote:
Doug,
I started writing the interface you put forth in your email.
Do you mind clarifying? Either it was a private email, or
one posted here, in which case there was an interpretation.
--
Luben
---
This SF.NET email
Alan Stern wrote:
Apparently it can't. I don't mean to say that this was the right thing to
do; I just meant that this is what Matt's currently-proposed patch does.
Personally, I'm not very familiar with the details of the SCSI subsystem,
and I don't know what preconditions are required for
Alan Stern wrote:
Are you aware that you are contradicting yourself?
On Fri, 24 Jan 2003, Luben Tuikov wrote:
A LLDD should and must *not* call scsi_unregister_host(). This brakes
all hierarchy.
What I probably meant is the detect()/release() pair; release() itself
normally calls
Matthew Dharm wrote:
It would be nice if the SCSI mid-layer kept track of what commands were in
what stages in who's queues.
My mini-scsi-core does exactly that. Moving commands between queues is atomic.
The whole thing is completely reentrant and multithreaded capable, etc, etc.
It has a simp
Alan Stern wrote:
>
Matt's current proposed patch has the USB LLDD calling
scsi_unregister_host() (because the device is respresented as an emulated
A LLDD should and must *not* call scsi_unregister_host(). This brakes
all hierarchy.
Let's not make a distinction between a USB LLDD and any LLD
Oliver Neukum wrote:
Very well, so you agree that the SCSI layer should export to the LLDD
a function to set devices offline?
I've never really disagreed -- simpler transports will make use
of such a function. The important point to note is that the error
return value for simpler and more comp
Oliver Neukum wrote:
Not all the world is a SAN. USB has no possibility to even try an interaction
after the device is gone. We have to handle this flexibly.
Thus the example in the original post. I.e. for simple transports whose
portals get notified when a device is plugged off (USB), the LLD
Alan Stern wrote:
Here's another question to add to your discussion.
When a device is unplugged, the system's representation of that device
can't be removed immediately; there may be open fd's, mounts, pointers,
and so on. Until the time comes when all these handles are released, all
interaction
Oliver Neukum wrote:
Am Dienstag, 21. Januar 2003 19:16 schrieb Luben Tuikov:
When the Low Level Device Driver (LLDD), being the transport portal,
notices that the device is going away or has gone away from the
``fabric'' (wlg), it will fire a device-gone event with the ke
Oliver Neukum wrote:
>
So a disconnection would look like this:
1.
scsi_set_offline_host(...);
2.
synchronize_kernel();
3.
error_queied_commands(...);
4.
scsi_remove_host();
Not quite. You want to do 3 before 2, to get 2 going as soon
as possible. Futhermore, 3 is partly in LLDD. 1 w
Oliver Neukum wrote:
Disconnect is not really a callback. There's a distinct lack of a back movement here.
khubd -> usbcore -> disconnect() in driver -> [layer on top]
The proposed API in SCSI looks like:
-> LLD -> midlayer -> top layer -> midlayer -> LLD with destroy_slave()
and that's not OK.
David Brownell wrote:
Luben Tuikov wrote:
The way this should work is that the LLD calls scsi_remove_device(), and
that cuts off the flow of commands. The LLD can promise to error-out
any
pending commands in the device command queue.
I take it you mean that the transport will tell the LLDD
Oliver Neukum wrote:
I take it you mean that the transport will tell the LLDD that the device
is gone and it (LLDD) call the one above, SCSI Core to remove the device.
Hmm, more thinking needs to be done here, as shouldn't this be handled
by hotplugging? I.e. Targets do not *initiate* events.
Th
Matthew Dharm wrote:
In a separate discussion with Mike, he mentioned that you can't
scsi_remove_device() unless there are no pending commands.
How the hell is an LLD supposed to assure that!?!?
ABORT TASK/ABORT TASK SET.
For a year now I've been trying to get something of the sort
scsi_cancel
Cress, Andrew R wrote:
I think SCSI-Core should care about offsets 36-48, since that is where the
serial number usually is returned. Special error handling for emulated
devices would be better than limiting the inquiry up front I think.
We were discussing the case when CmdDt = 0 and EVPD = 0.
T
Matthew Dharm wrote:
I'm told this is a bad idea because there are some HBA which snoop the
INQUIRY data. Since I don't know how that snooping works, I can't comment
further.
I do, in my own LLDDs. If anything the additional length might increase.
Others snoop it for their own awareness of the
Matthew Dharm wrote:
Perhaps the "best" fix here is to simply make scsi_scan.c only send 36 byte
inquiry requests if the bus is 'emulated'. That would solve a world of
problems
When scsi_scan.c does it's own scanning for SCSI Core, maybe it's best to
ignore 36 < INQUIRY_DATA_LEN < 57, sinc
Alan Stern wrote:
The SCSI code has no means of knowing the actual length transferred,
so has no choice but to believe the length byte in the reply.
But the USB code does the transferring itself, and knows precisely
how many bytes were transferred. If 36 bytes were transferred and
the additional
[EMAIL PROTECTED] wrote:
There are at least four replies:
The factual: It seems you are unaware of the present USB storage code.
For many devices the INQUIRY response is entirely fabricated.
I'm aware of this, but you were complaining of a new device
which you got, so I assumed the INQUIRY res
[EMAIL PROTECTED] wrote:
The SCSI code has no means of knowing the actual length transferred,
so has no choice but to believe the length byte in the reply.
But the USB code does the transferring itself, and knows precisely
how many bytes were transferred. If 36 bytes were transferred and
the addi
21 matches
Mail list logo
