Subject: Re: Per-thread user <-> kernel communication area
To: Bill Stouder-Studenmund <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 11/09/2007 16:42:38
On Nov 9, 2007, at 4:24 PM, Bill Stouder-Studenmund wrote:
> 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
>>> 2) What thoughts do you have for versioning this stuff?
>>> Specifically, I
>>> can see a utility in eventually having the app communicate some
>>> things to
>>> the kernel via this page. How do we avoid having either side end up
>>> 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
>>> 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 page?
>> At least then individual features can be added/removed without
>> breaking everything.
> This setup would easily be per-process, so we only need one overall
> of info.
I was thinking that you'd have a syscall manage what's contained in
By default, the page would be empty/unused. That syscall would add
use a component's use of the page.
>> Possibly even an array of fixed size type+value pairs - where the
>> 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
> 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
> requesting a version of it. I'm not clear what form this should take.
I think something more flexible.