Subject: Re: Per-thread user <-> kernel communication area
To: Andrew Doran <>
From: Bill Stouder-Studenmund <>
List: tech-kern
Date: 11/09/2007 16:24:44
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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:
> >=20
> > 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?
> >=20
> > 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
of info.

> 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
> exists.

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.

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.7 (NetBSD)