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, David Woodhouse wrote:
>
> > Same thing here. The __KERNEL__ approach says "whatever you want, boss".
> > It doesn't get in the way. Maybe it doesn't actively _help_ you either,
> > but you never have to fight any structure it imposes on you.
>
> Having to think before adding something that's user visible is a
> _benefit_ not a disadvantage.

I've said this at least three times: if you can point to a _specific_
thing you want to move, go wild. I think the big waste in this discussion
has been that there have _not_ been specific suggestions, just total
sound-bites like "wouldn't it be great to move things to 'include/kapi'".

If you have a specific thing in mind, say instead something like

"Wouldn't it be great if we moved all the tty layer IOCTL numbers
into 'tty-ioctl-nr.h', and made the old header file just include
that header file, so that new libc users can get them from just
that header? And btw, here's the patch."

then I might listen. Notice how the only really constructive thing to come
out of this flame-fest has been a patch by Al that looked perfectly
reasonable, but that got totally drowned out by the arguing?

Note that even _if_ you have a specific thing in mind, I want to see that
somebody would say "yes, we'd use that organization". I would not be
surprised at all if glibc people said that they can't really use any
re-organization anyway, since they need to support old kernel setups too.

See? Changes that aren't specific enough, or don't actually help things is
what I'm against.

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:1.173 / U:0.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site