![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-04-03 14:40 [from the cache] ©2003-2008 | |||||||||||||