lkml.org 
[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] Splitting kernel headers and deprecating __KERNEL__


On Tue, 30 Nov 2004, Alexandre Oliva wrote:
>
> - move anything that is not protected by #ifdef __KERNEL__ to the
> ukabi header tree, adding an include in the beginning of the original
> header that includes the ukabi header.

No. I want stuff that goes into the ABI tree to be clearly _defined_ to be
user-visible. Not a "let's move it all there and then prune it".

Leave anything questionable in the current location. And never EVER move
anything that is kernel-internal to a new "clean" tree, because that would
be totally pointless. At that point, people would have to edit the "clean"
tree even for kernel internal stuff. No go.

Also, "ukabi" just isn't going to fly as a name. It's also not as simple
as you seem to think, since a lot of these ABI things are architecture-
dependent, which apparently all you guys have totally ignored.

I've suggested "include/user/" and "include/asm-xxx/user", which handles
architecture-specific parts too. I'm ok with doing it the other way
around, ie "include/user/" and "include/user/arch-xxxx".

And "user" might be "user-abi" or something like that, but it sure isn't
going to be some unreadable contraction.

And I _still_ want to see these patches only for things where somebody can
validly argue that
(a) it can't break anything (ie the old location still includes the new
one, exactly the same way)
(b) there are people who will actually take _advantage_ of that
particular file (ie "just because I think so" doesn't fly).

Moving files around is just too disruptive to be done without damn good
reason.

Linus
-
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: 2009-11-18 23:46    [W:0.088 / U:0.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site