From: David Hinds <dhinds@sonic.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: unclean yanking out of device?
Date: Thu, 15 Jan 2004 21:22:07 +0000 [thread overview]
Message-ID: <20040115132207.B23434@sonic.net> (raw)
In-Reply-To: <20040114160002.G57254@forte.austin.ibm.com>
On Thu, 15 Jan 2004 12:38:53 -0600, linas@austin.ibm.com wrote:
> On Thu, Jan 15, 2004 at 11:17:31AM -0600, Richard Troth wrote:
> > > remove() is what notifies the pci driver that the device is about to go
> > > away. ...
> >
> > (cardbus aside)
> > Perhaps we need a removed() entry point?
> > Something that explicitly means "has already gone"
> > rather than implying "is about to go".
>
> That's exactly what I was thinking.
>
> This is based on the assumption that some device driver writers
> really want a remove() that is different from been_removed().
>
> Forcing a device driver writer to implement been_removed()
> only (as pcmcia does) does not give them the chance to clean
> up the way they might have wanted to if they could have assumed
> the device was still 'live', e.g. clean up some lock on some
> remote device (such as some iSCSI lock sitting on the disk drive
> or something, i dunno).
PCMCIA actually does not implement a "been removed" event. It reports
the removal as soon as possible, which will be while the hardware is
still available, if the user requested the removal before ejecting the
hardware. (the removal request is actually reported as another event,
and a driver can choose to field these events, and accept/deny the
requests)
Separate entry points for clean and unclean removal are not useful,
because the clean removal case has to be hardened against the device
going away while the removal is in progress... and once you've done
that, you'd might as well call the clean removal code even when you
know the hardware is already gone.
-- Dave
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
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:[~2004-01-15 21:22 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-14 22:00 unclean yanking out of device? linas
2004-01-14 22:15 ` Måns Rullgård
2004-01-14 22:19 ` Greg KH
2004-01-14 23:08 ` linas
2004-01-14 23:24 ` Greg KH
2004-01-14 23:49 ` Paul Ionescu
2004-01-14 23:57 ` linas
2004-01-15 0:19 ` Oliver Neukum
2004-01-15 0:19 ` Greg KH
2004-01-15 0:34 ` Greg KH
2004-01-15 0:36 ` David Brownell
2004-01-15 1:16 ` linas
2004-01-15 1:20 ` linas
2004-01-15 1:33 ` Greg KH
2004-01-15 1:35 ` Greg KH
2004-01-15 1:57 ` linas
2004-01-15 17:17 ` Richard Troth
2004-01-15 18:38 ` linas
2004-01-15 21:22 ` David Hinds [this message]
2004-01-24 0:38 ` Greg KH
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=20040115132207.B23434@sonic.net \
--to=dhinds@sonic.net \
--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).