>
> According to the various standards all symbols beginning with __ are
> reserved for "The Implementation", including the compiler, the
> standard library, the kernel, etc. In order to avoid clashing with
> any/all of those, I picked the __KABI_ and __kabi_ prefixes for
> uniqueness. In theory I could just use __, but there are problems
> with that too. For example, note how the current compiler.h files
> redefine __always_inline to mean something kinda different.
well... the "problem" is there today, and... it's not much of a problem
if at all; there's just a few simple rules to keep it that way which
seem to wkr.
And your __alway_inline example.. that's something that really is kernel
internal and shouldn't be exposed to userland.
I think the "problem" really is not there if
1) we only use __ symbols like we do today for non-structs
2) avoid including kernel headers in kernel headers as far as possible.
This means, that if an application wants to use MTD struct
"struct mtd_foo" it will have to include the MTD header, but that
he otherwise never gets it. Eg all such symbols are in a "Yes I
really want it" header.
3) keep the userspace exposed stuff as small as reasonable. Your
__always_inline example doesn't make that cut. A struct used as
ioctl of a subsystem/driver in the header specially for that
subsystem/driver does.
-
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]
