Re: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure

Arjan van de Ven
2006-04-02T13:09:19Z

On Sun, 2006-04-02 at 00:53 -0500, Kyle Moffett wrote:
> deal with compatibility: the kernel/userspace boundary. I'd like to
> strictly define all of that compatibility within a single set of
> _upstream_ headers in linux/include/linux-kabi or similar.

yes that was what I was hoping you meant

>
> But returning to your statements above, user code in that (C
> standards) context means anything not standard-specified.

I think you misread the C standard then. This only applies when you ONLY
include the headers defined in the standard, and no others.

> Basically,
> from userspace, a program that includes _any_ standard-specified
> header must bring in *only* those symbols specified by the standard
> as being present in that header, as well as any implementation-
> defined double-underscore symbols.

if you follow this argument then ANY library, be it glibc or gtk or
mysql or .. can only add __ things. That is not the case. Think of
"non-indirect" kernel header includes as including a header for a
library.

Maybe an example is needed: include/mtd/mtd-abi.h
Well it's a slightly bad example since it uses stdint.h types not __u64
types. But assume it used __u64 types, then this header would be
perfectly fine, including from a standards point of view.

> So unless I "#include
> <stdint.h>", my user program can typedef uint32_t to anything it
> wants, even a struct, if it likes.

yes this the example where __u64 needs underscores, and headers need to
use __u64 as they have to today.

> I've actually done that before on
> a very strange Cray platform with non-GCC compiler and OS that only
> supported 64-bit integers (a char was a 64-bit integer with ops to
> mask out the upper 56 bits), just to make bzip2 work as expected.
> The same rules apply for _every_ other standard-specified header
> (stdlib.h, stdio.h, sys/types.h, etc).

exactly. Nowhere is linux/* or asm/* in the standards as specified.

> to get access to them. Unfortunately this made it impossible to use
> those headers in userspace.

ok now I'm confused. How is providing FUNCTIONALITY such as setting
bitops the right thing for such headers? I would argue that the clean
headers should absolutely NOT do that but only provide the INTERFACE.

(this is also there for a license angle btw, if you actually start to
provide large bodies of code this way the lawyers will get unhappy wrt
the GPL; it's a LOT better to strictly do interface things only, eg
types, defines and prototypes)

In general:
I think you're focusing WAY too much on the __u64 kind of thing, which
is the vast minority of the ABI work, the ioctl structs are the big one.
For the __u64 kind of thing I would strongly suggest that you stick to
the currently already used symbols; anything existing knows to stay
clear of those already, so things are fine there so lets keep it simple
for those.