lkml.org 
[lkml]   [2006]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH 1/2] Create initial kernel ABI header infrastructure
From
Date

>
> 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 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-03-26 16:44    [W:0.133 / U:1.680 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site