--mSxgbZZZvrAyzONB
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=
=20
> > can see a utility in eventually having the app communicate some things =
to=20
> > 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=
=20
> > handle obsoleting stuff? Say we add something then, after having actual=
ly=20
> > tried it, realize that it's unworkable. How do we get rid of it?
>=20
> A thought on that is to encode a series of offsets at the start of the pa=
ge?
> 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.
>=20
> 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=
=20
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,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFHNPpMWz+3JHUci9cRAi6CAJsGnH1AELlQYgUBio+jBJqoglIpYwCfYkbA
r+uqBdLjrcafXGWQtAqnSCM=
=Ey6Z
-----END PGP SIGNATURE-----

--mSxgbZZZvrAyzONB--