scsi_set_host_offline (resend)
Quoted 7 lines
The way to think about this, I think, is "what would we do if the user asked nicely before removing the device" (i.e. requested device ejection rather than forced it). Then the above makes perfect sense because we have to start at the top and move down. Since requested ejection is the model for things like hotplug PCI busses, I'm hoping someone else is thinking about this.
No this is exactly the way not to ever think about this.
You are not asked to remove a device, you are informed it's gone. This is the case in all but sometimes one type of bus system in the kernel. And that is the way information has to flow. Strictly from the driver closest to the hardware up. And there must be no undue delay and neither failure. Failure to handle a removal is a contradiction in terms. This means that any call to user space must not be waited for in the kernel and failure must not be deadly. Filesystems must already be ready to deal with incorrectible errors. They are not your problem.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There! NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · Oliver Neukum
Quoted 6 lines
The way to think about this, I think, is "what would we do if the user asked nicely before removing the device" (i.e. requested device ejection rather than forced it). Then the above makes perfect sense because we have to start at the top and move down. Since requested ejection is the model for things like hotplug PCI busses, I'm hoping someone else is thinking about this.
Quoted 5 lines
No this is exactly the way not to ever think about this. You are not asked to remove a device, you are informed it's gone. This is the case in all but sometimes one type of bus system in the kernel. And that is the way information has to flow. Strictly from the driver closest to the hardware up.
This is correct.
Quoted 6 lines
And there must be no
undue delay and neither failure. Failure to handle a removal is a contradiction in terms. This means that any call to user space must not be waited for in the kernel and failure must not be deadly. Filesystems must already be ready to deal with incorrectible errors. They are not your problem.
We've discussed this before.
Userspace must be _notified_. Note the choice of verb. This doesn't *necessarily* mean that the kernel will wait on userspace to finish some action, but it may, but *not* necessarily -- this is to the discrection of the hotplug system working together with the kernel -- ``to each it's own''. I.e. for some hotplug events there maybe a userspace event involved and for others it may not.
There are several reasons for this, one of which is that the system administrator may want to know about the removal of a device. So why should userspace do some kind of polling, when the kernel can simply _notify_ userspace.
As to usb, you can fail all commands in due time, notify the subsystem above you (which will take over) and free your resources, and leave others to be freed by the subsystem above you which it registered. (ideally)
Signature · 20 lines
Luben P.S. We've all discussed this before, same set of ppl, same set of mailing lists. ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines
Quoted 6 lines
No this is exactly the way not to ever think about this. You are not asked to remove a device, you are informed it's gone. This is the case in all but sometimes one type of bus system in the kernel. And that is the way information has to flow. Strictly from the driver closest to the hardware up.
This is correct.
Good.
Quoted 7 lines
Quoted 6 lines
And there must be no
undue delay and neither failure. Failure to handle a removal is a contradiction in terms. This means that any call to user space must not be waited for in the kernel and failure must not be deadly. Filesystems must already be ready to deal with incorrectible errors. They are not your problem.
Quoted 8 lines
We've discussed this before.
Userspace must be _notified_. Note the choice of verb. This doesn't *necessarily* mean that the kernel will wait on userspace to finish some action, but it may, but *not* necessarily -- this is to the discrection of the hotplug system working together with the kernel -- ``to each it's own''. I.e. for some hotplug events there maybe a userspace event involved and for others it may not.
Please explain yourself further. We cannot deal with wait sometimes. Either we may wait or we may not wait. If we may wait,
we must always deal with it like we will wait and deal with results, which is impossible, as the only result we can deal with is success.
Notification is absolutely no problem. _Requiring_ the kernel to wait for user space to act so that the process of removal can be completed as far as the the low level driver is concerned is a major problem.
All is well if a low level driver can consider a device gone for good as soon as "/sbin/hotplug" is spawned. The key here is spawned , not doing something or finish, but spawned.
We have indeed discussed this before and the need to notify user space was never questioned, as far as I recall. The point of contention always was whether the notification had to do specific things for the process of unplugging to finish as far as it concerns the low level driver.
Quoted 4 lines
There are several reasons for this, one of which is that the system administrator may want to know about the removal of a device. So why should userspace do some kind of polling, when the kernel can simply _notify_ userspace.
Oh absolutely, sure.
Quoted 4 lines
As to usb, you can fail all commands in due time, notify the subsystem above you (which will take over) and free your resources, and leave others to be freed by the subsystem above you which it registered. (ideally)
That is what we hope for.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 2 lines · Oliver Neukum
Please explain yourself further. We cannot deal with wait sometimes.
No need to -- we agree.
Quoted 8 lines
Either we may wait or we may not wait. If we may wait,
we must always deal with it like we will wait and deal with results, which is impossible, as the only result we can deal with is success.Notification is absolutely no problem. _Requiring_ the kernel to wait for user space to act so that the process of removal can be completed as far as the the low level driver is concerned is a major problem.
No, a LLDD will not be required to wait on userspace. No one wants this and the fault in this is quite evident that no one would want it.
The only point is notification, and we seem to agree on this.
Quoted 3 lines
All is well if a low level driver can consider a device gone for good as soon as "
/sbin/hotplug" is spawned. The key here is spawned , not doing something or finish, but spawned.
Ideally:
You can assume even better than that: as soon as your interconnect tells you that the device is gone, a LLDD (= transport portal) does this:
---> calls xxx_dev_removal(dev) (marks device as gone in this subsystem), (and which in turn:
---> calls scsi_device_removal(dev) (mark dev as gone in this subsys),
... (see my other posting))
(none of which blocks, more work/discussion is needed here, but this is different topic)
and then the LLDD can free *its* resources which it allocated on the device.
*But*, the _important__point_ is that the LLDD must be able to handle requests (queuecommand()) to non-existant (= just removed) devices, and not oops, or whatever.
So, in effect, you just call usb_dev_removal(dev) (to be written), and free _your_ resources on the device. (note important point above)
Quoted 5 lines
We have indeed discussed this before and the need to notify user space was never questioned, as far as I recall. The point of contention always was whether the notification had to do specific things for the process of unplugging to finish as far as it concerns the low level driver.
Right. As far as I can see, those subsystem entries, xxx_dev_removal(dev), would do things which do not block, like flip a bit, flags, integer, wake up a thread, etc, call the above subsystem's xxx_dev_removal(dev), and return immediately. (as per my other posting)
(this needs more thinking though)
Signature · 14 lines
Luben ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 4 lines
*But*, the _important__point_ is that the LLDD must be able to handle requests (
queuecommand()) to non-existant (= just removed) devices, and not oops, or whatever.
For how long? That's the question.
Quoted 2 lines
So, in effect, you just call
usb_dev_removal(dev)(to be written), and free _your_ resources on the device. (note important point above)
The way it is in USB is a little different as the USB device drivers do not go directly to the hardware. It would be:
HCD -> USB core -> LLDD -> generic SCSI -> ...
Steps 1 to 3 work, 4 doesn't.
For a PCMCIA LLDD it would be different, but that really doesn't matter to the generic SCSI layer.
Quoted 11 lines
Quoted 5 lines
We have indeed discussed this before and the need to notify user space was never questioned, as far as I recall. The point of contention always was whether the notification had to do specific things for the process of unplugging to finish as far as it concerns the low level driver.
Right. As far as I can see, those subsystem entries,
xxx_dev_removal(dev), would do things which do not block, like flip a bit, flags, integer, wake up a thread, etc, call the above subsystem'sxxx_dev_removal(dev), and return immediately. (as per my other posting)
(this needs more thinking though)
If they can't block, they cannot clean up commands still in flight. Eventually something needs to wait for the outstanding commands.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 6 lines · Oliver Neukum
Quoted 3 lines
*But*, the _important__point_ is that the LLDD must be able to handle requests (
queuecommand()) to non-existant (= just removed) devices, and not oops, or whatever.For how long? That's the question.
As soon as scsi_dev_removal()/scsi_set_dev_offline() returns you may assume you can free all _your_ resources. I.e. the upper subsystem should handle it from that point on.
Quoted 9 lines
Quoted 2 lines
So, in effect, you just call
usb_dev_removal(dev)(to be written), and free _your_ resources on the device. (note important point above)The way it is in USB is a little different as the USB device drivers do not go directly to the hardware. It would be:
HCD -> USB core -> LLDD -> generic SCSI -> ...
Steps 1 to 3 work, 4 doesn't.
Not yet, soon maybe.
Quoted 2 lines
If they can't block, they cannot clean up commands still in flight. Eventually something needs to wait for the outstanding commands.
I don't see it.
(Upper level: )
Pending commands could be invalidated at once, via their callback to the upper subsystem; and any new incoming commands to device x could be invalidated at the moment they come in.
(Lower level: )
Note that during the call to scsi_dev_removal() your driver may get its host_reset/device_reset function called to abort all pending commands (so as to leave the device in a predictable state). At which point, depending on the transport, _your__driver_ may need to sleep until the task management function response comes back (say over a network).
All in all, it's not that bad.
Signature · 15 lines
Luben ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel