On Sep 10, 2005, at 20:48:18, Andrew Morton wrote:
1) At some point the arch/driver/etc maintainers (for anything that
interacts with userspace), need to start converting things on their
own (such as moving ioctl and struct declarations to a <kabi/*.h>
header file), because the people working on it certainly don't have
all the varieties of hardware and userspace programs that would be
affected by this change.
This will be very disruptive.
I know, but currently it places a lot of unnecessary load on the
linux-libc-headers maintainer, and sometimes that doesn't get done
correctly. For most of the above, all the maintainer will need to
do is move the ioctl and struct declarations necessary in userspace
from the header file in linux/ to a corresponding one in kabi/,
_maybe_ change a few macro names, and then verify that it all still
works correctly.
2) The goal is to minimize changes to kernel code. I'm not out to
rename "struct list_head", that would be silly! Instead, the header
<linux/list.h> would be basically reduced to this:
#ifndef __LINUX_LIST_H
# define __LINUX_LIST_H 1
# ifdef __KERNEL__
# define __kcore_list_item list_head
# include <kcore/list.h>
# define list_add(x,y) __kcore_list_add(x,y)
[...etc...]
# endif /* __KERNEL__ */
#endif /* not __LINUX_LIST_H */
I hope list.h was a poorly-chosen example, and that there are no
plans to
actually do anything like the above to list.h.
Yeah, that was actually a rather poorly chosen example, but it
does somewhat illustrate the way we would preserve compatibility.
Surely the only files which need to be altered are those which we can
reasonably expect userspace to actually include.
Yeah. I would have given one of the types.h files, except those
are so massively chaotic and with all sorts of cross dependencies
that I haven't tinkered with them enough yet. I'm working on it,
though!
3) Another side effect of this project will be that we will have
the chance to clean up and merge some of the stuff currently in
the asm-* directories.
I'd suggest that you avoid side-effects. Unrelated cleanups are
unrelated
- do it as a separate project.
My plan is to start with a bunch of cleanups that make it easier
to split the files, and then proceed to begin splitting the low
level files that are essential to everything else. Once that's
done, I would move on to the other headers, the ones that have
dependencies on lots of headers. I'll probably have to submit
cleanups to stuff like linux/kernel.h, linux/sched.h, etc, to
prevent include cycles.
I'm very dubious about the whole idea, frankly.
This would make life a million times easier for the UML people,
the glibc people, the klibc people, and the linux-libc-headers
maintainer (IE: you don't need one, and he can go do something
more productive), etc. If you want proof, several of the above
groups have previously voiced in support of this project in
this very thread.
This is definitely not a short-term project, and will really only
reach significant improvements for those groups by around
2.6.30 or so, but many feel it's a necessary change.
Cheers,
Kyle Moffett
--
I lost interest in "blade servers" when I found they didn't throw
knives at
people who weren't supposed to be in your machine room.
-- Anthony de Boer
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |