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

[Arjan van de Ven <arjan@infradead.org>]

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.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/