public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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

  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