[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20061123115504.GB20294@2ka.mipt.ru>
Date: Thu, 23 Nov 2006 14:55:04 +0300
From: Evgeniy Polyakov <johnpol@....mipt.ru>
To: Ulrich Drepper <drepper@...hat.com>
Cc: 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>,
linux-kernel@...r.kernel.org, Jeff Garzik <jeff@...zik.org>
Subject: Re: [take25 1/6] kevent: Description.
On Wed, Nov 22, 2006 at 03:52:11PM -0800, Ulrich Drepper (drepper@...hat.com) wrote:
> Evgeniy Polyakov wrote:
> >+ struct kevent_ring
> >+ {
> >+ unsigned int ring_kidx, ring_uidx, ring_over;
> >+ struct ukevent event[0];
> >+ }
> >+ [...]
> >+ring_uidx - index of the first entry userspace can start reading from
>
> Do we need this value in the structure? Userlevel cannot and should not
> be able to modify it. So, userland has in any case to track the tail
> pointer itself. Why then have this value at all?
>
> After kevent_init() the tail pointer is implicitly assumed to be 0.
> Since the front pointer (well index) is also zero nothing is available
> for reading.
uidx is an index, starting from which there are unread entries. It is
updated by userspace when it commits entries, so it is 'consumer'
pointer, while kidx is an index where kernel will put new entries, i.e.
'producer' index. We definitely need them both.
Userspace can only update (implicitly by calling kevent_commit()) uidx.
> --
> ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View,
> CA ❖
--
Evgeniy Polyakov
-
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