From: Davide Libenzi <davidel@xmailserver.org>
To: Michael Kerrisk <mtk.manpages@googlemail.com>
Cc: Pierre Habouzit <madcoder@debian.org>,
lkml <linux-kernel@vger.kernel.org>,
Eric Dumazet <dada1@cosmosbay.com>,
Marc Lehmann <schmorp@schmorp.de>,
David Schwartz <davids@webmaster.com>
Subject: Re: epoll and shared fd's
Date: Tue, 26 Feb 2008 11:31:21 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0802261125180.27243@alien.or.mcafeemobile.com> (raw)
In-Reply-To: <cfd18e0f0802261114v4d4891bcy107bba2a181c1146@mail.gmail.com>
On Tue, 26 Feb 2008, Michael Kerrisk wrote:
> Okay -- I'll look at it some more. I am however loathe to drop the
> term open file description, because POSIX uses, as well as a number of
> other Linux man pages by now.
Heh, POSIX. Now doesn't take a genius to see that "file description" and
"file descriptor" looks amazingly similar, does it? :)
> > That'd mean placing an eventpoll custom hook into sys_close(). Looks
> > very bad to me, and probably will look even worse to other kernel
> > folks. Is not much a performance issue (a check to see if a file* is
> > an eventpoll file is as easy as comparing the f_op pointer), but a
> > design/style issue.
>
> Oh -- I wasn't suggesting we could make the change now -- it would
> break the ABI and all that. I was just wondering why the decision
> wasn't made to do it the other way to begin with. The existing
> semantics are somewhat couterintuitive, and potentially interact
> libraries that do private manipulations with file descriptors.
For the same reason that a custom hook in sys_close wouldn't have passed
the radar ;)
As far as problems with libraries doing tricks with fds, that's an issue
that goes beyond epoll.
- Davide
next prev parent reply other threads:[~2008-02-26 19:31 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-18 13:43 Pierre Habouzit
2008-01-18 21:10 ` Davide Libenzi
2008-01-24 8:40 ` Pierre Habouzit
2008-01-24 23:57 ` Davide Libenzi
2008-01-26 7:37 ` Michael Kerrisk
[not found] ` <Pine.LNX.4.64.0801261308270.10472@alien.or.mcafeemobile.com>
2008-02-26 15:13 ` Michael Kerrisk
2008-02-26 19:04 ` Davide Libenzi
2008-02-26 19:14 ` Michael Kerrisk
2008-02-26 19:31 ` Davide Libenzi [this message]
[not found] <9MZLT-1YO-33@gated-at.bofh.it>
[not found] ` <9N6Ng-5tn-21@gated-at.bofh.it>
[not found] ` <9P5WE-33i-11@gated-at.bofh.it>
[not found] ` <9Pk9l-1KA-1@gated-at.bofh.it>
[not found] ` <9PNNZ-b0-5@gated-at.bofh.it>
[not found] ` <a19Lb-1F0-13@gated-at.bofh.it>
[not found] ` <a19Lb-1F0-11@gated-at.bofh.it>
2008-02-26 18:16 ` Bodo Eggert
2008-02-28 12:10 ` Michael Kerrisk
2008-02-28 19:17 ` Bodo Eggert
2008-02-28 19:30 ` Davide Libenzi
2008-02-28 13:53 ` Valdis.Kletnieks
2008-02-28 15:08 ` Michael Kerrisk
2008-02-28 19:27 ` Davide Libenzi
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=Pine.LNX.4.64.0802261125180.27243@alien.or.mcafeemobile.com \
--to=davidel@xmailserver.org \
--cc=dada1@cosmosbay.com \
--cc=davids@webmaster.com \
--cc=linux-kernel@vger.kernel.org \
--cc=madcoder@debian.org \
--cc=mtk.manpages@googlemail.com \
--cc=schmorp@schmorp.de \
/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
all inboxes | Powered by JetHome®