Message-ID: <45335BEF.7010405@redhat.com>
Date:	Mon, 16 Oct 2006 03:16:15 -0700
From:	Ulrich Drepper <drepper@...hat.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
CC:	Eric Dumazet <dada1@...mosbay.com>,
	lkml <linux-kernel@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...l.org>, netdev <netdev@...r.kernel.org>,
	Zach Brown <zach.brown@...cle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Chase Venters <chase.venters@...entec.com>,
	Johann Borck <johann.borck@...sedata.com>
Subject: Re: [take19 1/4] kevent: Core files.

Evgeniy Polyakov wrote:
> The whole idea of mmap buffer seems to be broken, since those who asked
> for creation do not like existing design and do not show theirs...

What kind of argumentation is that?

    "Because my attempt to implement it doesn't work and nobody right
     away has a better suggestion this means the idea is broken."

Nonsense.

It just means that time should be spend on thinking about this.  You cut 
all this short by rushing out your attempt without any discussions. 
Unfortunately nobody else really looked at the approach so it lingered 
around for some weeks.  Well, now it is clear that it is not the right 
approach and we can start thinking about it again.


> You seems to not checked the code - each event can be marked as ready 
> only one time, which means only one copy and so on.
> It was done _specially_. And it is not limitation, but "new" approach.

I know that it is done deliberately and I tell you that this is wrong 
and unacceptable.  Realtime signals are one event which need to have 
more than one event queued.  This is no description of what you have 
implemented, it's a description of the reality of realtime signals.

RT signals are queued.  They carry a data value (the sigval_t object) 
which can be unique for each signal delivery.  Coalescing the signal 
events therefore leads to information loss.

Therefore, at the very least for signal we need to have the ability to 
queue more than one event for each event source.  Not having this 
functionality means that signals and likely other types of events cannot 
be implemented using kevent queues.


> Queue of the same signals or any other events has fundamental flawness
> (as any other ring buffer implementation, which has queue size)  -
> it's size of the queue and extremely bad case of the overflow.

Of course there are additional problems.  Overflows need to be handled. 
  But this is nothing which is unsolvable.


> So, the same event may not be ready several times. Any design which
> allows to create infinite number of events generated for the same case
> is broken, since consumer can be in situation, when it can not handle
> that flow.

That's complete nonsense.  Again, for RT signals it is very reasonable 
and not "broken" to have multiple outstanding signals.


> That is why poll() returns only POLLIN when data is ready in
> network stack, but is not trying to generate some kind of a signal for 
> each byte/packet/MTU/MSS received.

It makes no sense to drag poll() into this discussion.  poll() is a very 
limited interface.  The new event handling is supposed to be the 
opposite, namely, usable for all kinds of events.  Arguing that because 
poll() does it like this just means you don't see what big step is 
needed to get to the goal of a unified event handling.  The shackles of 
poll() must be left behind.


> RT signals have design problems, and I will not repeate the same error
> with similar limits in kevent.

I don't know what to say.  You claim to be the source of all wisdom is 
OS design.  Maybe you should design your own OS, from ground up.  I 
wonder how many people would like that since all your arguments are 
squarely geared towards optimizing the implementation.  But: the 
implementation is irrelevant without users.  The functionality users (= 
programmers) want and need is what must drive the implementation.  And 
RT signals are definitely heavily used and liked by programmers.  You 
have to accept that you try to modify an OS which has that functionality 
regardless of how much you hate it and want to fight it.


> Mmap implementation can be added separately, since it does not affect
> kevent core.

That I doubt very much and it is why I would not want the kevent stuff 
go into any released kernel until that "detail" is resolved.

-- 
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
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