On Thu, Oct 20, 2011 at 05:47:21PM -0400, Thor Lancelot Simon wrote:
> On Thu, Oct 20, 2011 at 06:54:54PM +0200, Manuel Bouyer wrote:
> > >
> > > I don't see why it's desirable to manifest such large objects when
> > > it's easily avoidable.
> >
> > We don't agree on "easily".
>
> FYI: I just went around, and around, and around on this with the
> configuration framework a proprietary kernel subsystem. If you just
> take the position that _any_ write to _any_ part of the data invalidates
> all cursors it is not so bad. The user application has to be coded to
> deal with that, but it keeps the complexity out of the kernel.
I think, if we go this way, the kernel/userland interface should have
an opaque pointer to the next data (returned by kernel) and a generation
number (also returned by the kernel). On next call the userland provide
again the opaque pointer and generation number; if the generation number
changed the kernel will return EAGAIN. A single 64bit opaque value could
work, but it's less convenient ...
--
Manuel Bouyer <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
