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  
>> 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 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  
>>> actually
>>> 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  
>> completely
>> breaking everything.
>
> This setup would easily be per-process, so we only need one overall  
> page
> of info.

I was thinking that you'd have a syscall manage what's contained in  
the page.
By default, the page would be empty/unused.  That syscall would add  
or remove
use a component's use of the page.

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