Re: [PATCH] scsi_set_host_offline (resend)

Re: [PATCH] scsi_set_host_offline (resend)

[Oliver Neukum]

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] scsi_set_host_offline (resend)

[Luben Tuikov]

Oliver Neukum wrote:
>>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.

This is correct.

> 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)

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] scsi_set_host_offline (resend)

[Oliver Neukum]

> > 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.

> > 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.

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.

> 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.

> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] scsi_set_host_offline (resend)

[Luben Tuikov]

Oliver Neukum wrote:
> 
> Please explain yourself further. We cannot deal with wait sometimes.

No need to -- we agree.

> 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.
 
> 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)

> 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)

-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] scsi_set_host_offline (resend)

[Oliver Neukum]

> *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.

> 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.

> > 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)

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: [PATCH] scsi_set_host_offline (resend)

[Luben Tuikov]

Oliver Neukum wrote:
>>*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.
 
>>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.

> 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.
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel