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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
