ABI compatibility boundary in userspace

["Aaron J. Grier" <agrier%poofygoof.com@localhost>]

On Thu, Aug 21, 2008 at 11:00:31AM -0700, Jason Thorpe wrote:
> On Aug 21, 2008, at 3:37 AM, David Brownlee wrote:
> > At the risk of suggesting a compromise which noone likes, we could
> > put the .a files into a separate 'static dev' set which sysinst sets
> > to not-installed by default...
> 
> This partially defeats the purpose.  The main reason for doing this is  
> to move the ABI compatibility boundary out into userspace where it  
> belongs.

why that is a good idea?  this by definition exposes userland to more
changes in the kernel, and instead of keeping the API to a single module
(the kernel) it's proposed to be split across the kernel and at least
one separate module in userland?  why introduce extra complication?
what problem is this trying to solve?

I don't see how this can be done without adding complexity to the
upgrade/downgrade process.  can you give me a use case of the problem
you are trying to solve?

I don't see how this can be a good thing.  this proposal removes a
common case of booting a new kernel with old userland.  I exploit that
behavior every time I do a system upgrade, and when tracking -current to
verify if a bug has been fixed, before commiting to the new userland.
I've always figured it as a useful feature.

how do I deploy these (kernel + compat library) packages, and how do I
drop back if the new ones don't work?  the only way I can think of
mitigating this is to start linking the compatibility library with the
kernel so they can be deployed as a single unit.

> I want the message to be "if you do this, you are on your  own... we
> make no guarantees about binary compatibility", and  providing an easy
> way to install the static libraries dilutes the  message.

OK, so the static library issue is just a side-effect of the intent to
push the ABI compatibility boundary away from the kernel.  that changes
things quite a bit.

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | 
agrier%poofygoof.com@localhost