lkml.org 
[lkml]   [2002]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] DEVFS_NOTIFY_ASYNC_OPEN removal
Date
On 24 November 2002 06:42, Alexander Viro wrote:
> Hmm... There's a very odd devfs feature that
> (a) is unused by anybody, AFAICS
> (b) is unusable as it is
> (c) is poorly documented
> (d) adds rather odd code
>
> The feature in question is:
> * when /dev/vc/<n> is opened the first time, event is sent to
> devfsd. Said event might be delivered at any point afterwards -
> open() doesn't wait for anything. Event bears (euid,egid) of the
> opener, which is pretty much guaranteed to be (0, <whatever>). In
> any case, by the time when devfsd receives the event, device might be
> already closed and opened by another process - without any events
> sent.
> * when memory pressure finally flushes dentry of /dev/vc/<n>
> devfsd gets another event and everything returns to original state.
> That event also bears (euid,egid) of task in question, which can be
> anything and has no relation whatsoever to task(s) that had ever done
> something with /dev/vc
> * as said above, any open/close on /dev/vc/<n> between the first
> one and the moment when dentry gets flushed (which can happen after
> unpredictable delay - e.g. at the umount time) doesn't generate any
> events.
>
> Surprise, surprise, that feature is impossible to use in any
> meaningful way. As far as I can see, nobody actually uses it.
>
> I have no idea what kind of use _was_ intended - why would anyone
> want to notify userland about some attempts to open virtual consoles
> with random delay after the event in question... Hell knows. It
> definitely can't be used for any "let's grant them extra permissions"
> scheme, due to asynchronous nature of that animal (and 1001 other
> reasons).
>
> In any case, it's unusable and unused. As for the poor
> documentation, just take a look at devfsd(8) and see what it says
> about the events in question:
> <quote>
> ASYNC_OPEN
> The inode was opened (the opening process does not
> wait for a response).
>
> CLOSE The file was closed.
> </quote>
> Note that both are generated only on /dev/vc/* and even on these not
> every open/close gives aforementioned events (see above for details).
>
> Semantics above had been there since before the merge into the tree.
> Do we really want to keep that junk?

Al, I'm surprized you are working on a feature you personally don't use
(and don't like). Not many people are willing to do this. You are something.

If those events (do not) work as you described 'em, that code can be nuked.

Richard, maybe code has rotten? What was an original intent of said events?
--
vda
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.902 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site