Re: [RFC] Splitting kernel headers and deprecating __KERNEL__

["Alexander Stohr" <alexander.stohr@gmx.de>]

> Matthew Wilcox wrote:
> > Indeed.  We could also make this transparent to userspace by using a script
> > to copy the user-* headers to /usr/include.  Something like this:

some administrator would like to only create symlinks for saving disk space.

others would like a true "install" with copying files so that they can delete
the kernel sources anytime they do want.

for me i would install all those kernel realted files into 
the well known /lib/modules/<kernel-version>. 
so its a no question that a single kernel install 
can be cleaned up by deleting those dir recursively.

the only part remaining somewhere else in the filesystem
would then be /boot/bzImage since booting is a special case.
there are several architectures where the bzImage is be able 
to reside in /lib/modules/... but there are others archs as well.

David Woodhouse wrote:
> Matthew Wilcox wrote:
> > If we really wanted to get fancy, we could also sed __u32 to uint32_t.
> > But that would probably cause more pain, confusion, hurt and bad feeling
> > than I'd ever want to be responsible for.
> 
> Also true. Let's just use the standard types in the first place and not
> screw around with having to fix it up later.

uint32_t is the type you should get when using the standarized statement
  #include <stdint.h>
Am i right? Does that header belong to the international C99 Standard?
So you are suggesting the kernel interface should stick to that standard?

Changing it that way would hit a noticeable amount of non kernel code.
Lets consider the opposite point of view. If we do postpone such a
change to the standards for some 3 to 10 more years, then i expect
the impact on software and problem for getting it solve is bigger.

Maybe that sort of change is something qualified for beeing done 
inside a true development kernel tree like Linux 2.7.xx which might
then beeing qualified for getting a Linux 3.0.0 release kernel tree.

-Alex.