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 kernel.
*Not* necessarily with SCSI Core, in fact I'd rather it didn't,
but with a well defined kernel entry for device-gone events.
Well, we are in feature freeze. I see no alternative but to notify
the mid layer. Who else but the mid layer knows what a physical device
is logically associated with?
Yes, we're in feature freeze. I realize this and the fact
that this may be 2.7 work, but it's nevetheless worth
to brainstorm the issue.
I think one needs to notify at a higher level -- (some) decision making
may/will be made there. SCSI Core will be notified eventually, or maybe
right away. For all we know, the policy of removing a device could
be to just go into SCSI Core with the removal -- but the point is
that you need to notify at a higher level.
In due time, SCSI Core has no problem with a device disappearing.
As I mentioned already, the event will ``bubble down'' to SCSI Core,
at some point or immediately.
At the same time the LLDD will start returning TARGET gone, or
whatever is appropriate to newly queued commands, and error out
all internally queued commands (if it does it's own queuing).
(I've seen this work nicely on mount and read/write(2) and fsck.)
Right.
I've been saying (repeating) this for my last 3-4 emails. Glad to
hear we've come to some kind of agreement. :-)
I.e. the ``synchronization'' has started already by the LLDD erroring
out commands, new and queued.
All the while the kernel has started higher level cleaning up,
decrementing ref counts, etc, stuff which may not be so easy to be
cleaned up just by LLDD returning TARGET error. Even though,
You cannot really make anything depend on errors returned, because
there simply may not be any commands queued. You can make it a
Exactly. The more reason to have a notification even at a higher
level, because *if* you had users and whatnot using the device
then you'd want to let them/it know. You need a higher level hook.
I can see a ton of uses for such a higher level hook.
requirement for an LLDD to return all commands in flight with an error,
but you can do little with these errors. Basically you have to treat them
As I've said, I've seen this method work nicely with mount and
fsck -- they time out almost right away, with different errors
of course, but LLDD returns TARGET error all the while.
So, either way (users or none), a higher level hook would seem
like a more general approach.
like uncorrectable errors, except maybe for the error code returned to
user space. But the processing of the disconnect itself should be triggered
by the LLDD's notification, because it's the only indication of an unplug
event you are sure to get.
I think this is the first thing I mentioned yesterday when I wrote
``transport initiated event''.
good design dictates that complete cleaning up should happen just
by the LLDD returning TARGET error (e.g. on mount), we *have* to allow
for this immediate high level entry point (as I mentioned above)
notification, which will be kind of ``meeting place'' for events like this.
That I don't understand. It would seem to me to be cleanest to have just
one path to process a disconnect event.
I also think that there should be one path: LLDD starts returning
TARGET error and all the while cleaning up has started from the top.
Depending on what needs to be done at those ``higher'' levels, the
event will eventually bubble down to the SCSI Core with something like
scsi_remove_device() which will do slave_destroy() in the driver.
The point is that at that point in time, it will be *safe* to do
scsi_remove_device() as all ULP have alreay been notified, and they've
relinquished their use of the LLD (Low Level Device), thus the safety.
But there can be no users of the LLDD at this point. There can of
course be references to devices and hosts, but not really uses.
The more reason for a higher level hook -- you see, it generalizes
the cases of users and no users using the device -- you have it covered
both ways. See my comments above.
After we have done a notification of the event the first things to do
are to make further opening of the device fail and make sure no more
commands are sent to the device. Likewise all queued commands have
returned with an error. So at this point it's impossible to use an unplugged
device.
So here I take it you agree with me.
But there's no such thing as ``waiting around indefinitely'' or
``blocking wait'' as you've suggested in some of your emails.
Even if this UL entry point doesn't do anything, ref counts should
go to zero, after all users error out on this device, at which point
the user can remove the device from *the system* by hand/old method
through proc or whatever finalizes for 2.6.
You cannot be sure that reference counts will go to zero ever.
You can be sure that they won't increase as you can fail any operation that
would cause them to increase, but you cannot force userland to close its fds.
And waiting for somebody to remove a device is wrong. It's gone physically.
There's no choice but to remove it. The refcounts can tell you when to free
data structures associated with devices, but what else do you want them to do?
A agree with all this. What I was saying is the flexibility of the policy.
Yes, it is correct that we cannot force userland to close its fd's.
Just as you cannot force a parent process to collect child exit status :-) .
(Idea!)
I'm glad to see we're coming to an agreement.
--
Luben
-------------------------------------------------------
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
