[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d120d5000704200935s6aacf367ncc229f5bb95b1e12@mail.gmail.com>
Date: Fri, 20 Apr 2007 12:35:19 -0400
From: "Dmitry Torokhov" <dmitry.torokhov@...il.com>
To: "Alan Stern" <stern@...land.harvard.edu>
Cc: "Tejun Heo" <htejun@...il.com>,
"Cornelia Huck" <cornelia.huck@...ibm.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
"Greg K-H" <greg@...ah.com>,
"Rusty Russell" <rusty@...tcorp.com.au>
Subject: Re: [PATCH RFD] alternative kobject release wait mechanism
On 4/19/07, Alan Stern <stern@...land.harvard.edu> wrote:
>
> Among the worst offenders are character devices. None of the subsystem
> providers offering char device registration performs immediate detach --
> they are a lot like sysfs used to be. (In fact, they probably _can't_
> provide it since read() or write() calls can block indefinitely in the
> lower-level driver; the subsystem may have no way to force them to
> fail-fast.)
That shoudl be doable - the read/write routines should check if device
is still alive and return immideately when device is dead. When
disconnecting device just wake up all readers and writers and they
should eventually fall off.
Hmm, I guess am starting to think that using refcounting everywhere is
not a good idea. We are trying to have "immediate disconnect" behavior
and refcounting is an antithesis of it. Refcounting works well when it
is contained - register grabs reference; unregister puts it back; but
there is no passing references down between the layers. When device is
being removed it needs to signal downstream that it is gone and should
not be accessed anymore. And we need to do that anyway because if
device is really gone but its users ignore it they will get endless
stream of errors when trying to access it.
--
Dmitry
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists