[lkml]   [2004]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2009-11-18 23:46    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean