From: Oliver Neukum <oliver@neukum.org>
To: linux-hotplug@vger.kernel.org
Subject: Re: [PATCH] scsi_set_host_offline (resend)
Date: Wed, 09 Apr 2003 22:32:10 +0000 [thread overview]
Message-ID: <marc-linux-hotplug-104992760832526@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-104904525413997@msgid-missing>
> > 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
next prev parent reply other threads:[~2003-04-09 22:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-03-30 17:26 [PATCH] scsi_set_host_offline (resend) Oliver Neukum
2003-04-09 20:30 ` Luben Tuikov
2003-04-09 22:32 ` Oliver Neukum [this message]
2003-04-09 22:59 ` Luben Tuikov
2003-04-10 7:51 ` Oliver Neukum
2003-04-17 22:29 ` Luben Tuikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-linux-hotplug-104992760832526@msgid-missing \
--to=oliver@neukum.org \
--cc=linux-hotplug@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).