From: Linus Torvalds <torvalds@linux-foundation.org>
To: Davide Libenzi <davidel@xmailserver.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Ingo Molnar <mingo@elte.hu>,
David Miller <davem@davemloft.net>
Subject: Re: [patch 3/7] epoll keyed wakeups - introduce key-aware wakeup macros
Date: Fri, 30 Jan 2009 19:49:26 -0800 (PST) [thread overview]
Message-ID: <alpine.LFD.2.00.0901301949110.3150@localhost.localdomain> (raw)
In-Reply-To: <send-serie.davidel@xmailserver.org.16376.1233372317.3>
On Fri, 30 Jan 2009, Davide Libenzi wrote:
>
> The following patch introduces new kwake_* macros that accepts an
> extra key parameter to be specified in the wakeup.
I really hate the naming.
> I chose to add an initial 'k' to the original names, instead of adding
> a whole "_key", since the name of some of those macros is becoming
> awfully long. No problem in using the "_key" naming, if others feel it.
> Comments?
That whole "kwake" thing makes me just think mis-spelling, so it does need
to change.
But even more I dislike the notion of this being a "key". It's not. It's
about poll events, nothing more. So renaming it to "_key()" in no way
helps.
Yes, _internally_ we send that "void *key" around, and then leave it to
lower levels to agree about how it is used, but at the level _you_ then
use it, that is no longer the case. When you do a
kwake_up_interruptible(&tty->write_wait, POLLOUT);
that has _nothing_ to do with "keys" any more. So the 'k' prefix is wrong
and really odd-looking, but a '_key' postfix wouldn't be much better
either. Because when you pass in POLLOUT, you're not using it as a key,
you are very much using it as a poll-specific thing.
So the naming should match that. I suspect a '_poll' postfix (or a 'poll_'
prefix would work and make sense.
So apart from that hating, I think the internal implementation and the use
of the existing 'key' parameter is fairly sane. The only downside is that
we've now really used up that key thing for something very epoll-specific,
but I don't see any better use for it, so I guess that's not a big
downside.
Oh, and numbers, please. How big of a win is this, really? Preferably with
something that really uses epoll for something real.
Linus
next prev parent reply other threads:[~2009-01-31 3:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-31 3:25 [patch 3/7] epoll keyed wakeups - introduce key-aware wakeup macros Davide Libenzi
2009-01-31 3:30 ` Ingo Molnar
2009-01-31 3:50 ` Davide Libenzi
2009-01-31 3:57 ` Linus Torvalds
2009-01-31 13:06 ` Ingo Molnar
2009-01-31 18:57 ` Davide Libenzi
2009-01-31 9:25 ` Alan Cox
2009-01-31 19:03 ` Davide Libenzi
2009-01-31 3:49 ` Linus Torvalds [this message]
2009-01-31 4:01 ` Davide Libenzi
2009-01-31 4:57 ` wli
2009-01-31 19:08 ` Davide Libenzi
2009-01-31 21:28 ` wli
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=alpine.LFD.2.00.0901301949110.3150@localhost.localdomain \
--to=torvalds@linux-foundation.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=davem@davemloft.net \
--cc=davidel@xmailserver.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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