Subject: Re: Per-thread user <-> kernel communication area
To: Andrew Doran <firstname.lastname@example.org>
From: Bill Stouder-Studenmund <email@example.com>
Date: 11/09/2007 16:24:44
Content-Type: text/plain; charset=us-ascii
On Fri, Nov 09, 2007 at 08:55:54AM +0000, David Laight wrote:
> On Thu, Nov 08, 2007 at 04:33:08PM -0800, Bill Stouder-Studenmund wrote:
> > 2) What thoughts do you have for versioning this stuff? Specifically, I=
> > can see a utility in eventually having the app communicate some things =
> > the kernel via this page. How do we avoid having either side end up=20
> > waiting for something the other doesn't know to do?
> > A sub-comment of the above, once we've added more stuff, how would we=
> > handle obsoleting stuff? Say we add something then, after having actual=
> > tried it, realize that it's unworkable. How do we get rid of it?
> A thought on that is to encode a series of offsets at the start of the pa=
> At least then individual features can be added/removed without completely
> breaking everything.
This setup would easily be per-process, so we only need one overall page=20
> Possibly even an array of fixed size type+value pairs - where the value
> might be an offset into the page.
> The layout would be fixed for the kernel, but userspace would have to
> scan it (probably once only?) to determine if a specific structure
The thing is that that's backwards of how we normally handle=20
compatability. Well, figuring the offsets isn't a problem. Making sure the=
values you want are available at any offset could be a problem.
For this shared page to work, I think we need a syscall from libc=20
requesting a version of it. I'm not clear what form this should take.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)
-----END PGP SIGNATURE-----