* Sat, 8 Sep 2007 08:08:06 -0400 (EDT)
All this is userspace code, ugly, unmaintained and all that kind of
things.
== Kernel panics without userspace, do you need such kernel? ==
The klibc project[0] was started 5 years ago to have usable kernel early
userspace with *usable* userspace. Status still unknown, but still better
than anything else in every distro, having NIH things just to boot-up
Linux.
[0] http://www.zytor.com/mailman/listinfo/klibc
I'd like to propose KJ as well as KN to look on that project and start to
be real userspace geeks first, before touching kernel and it's real
developers with (hopefully non-silly) stuff. Benefits:
* better understanding basic problems, like userspace API/ABIs
* know "how to" and actual produce tests easily
* improve development process: tools, ways of doing dev. thing, etc.
* have better results with kernel patches
My opinion is, that real developer must be very good user first. And
ordinary tools for that are shell, core utils (compare usage of it for
instance[1,2]). Having almost zero review of kernel development tools usage
and algos, complicated by people like Adrian[2], is not place to go in future
(and present, btw).
[1] http://marc.info/?l=linux-kernel&m=118868338702120
[2] http://marc.info/?l=linux-kernel&m=118911074923392
Only active kbuild developer -- Sam is almost always reply to poking
messages in form of "not much time for kernel-work"[2]. This is main
reasot to have kbuild system split per directory basis. Where most top
ones are actual subsystems. Scripting, inside those directories is due
of local developers/maintainers.
This includes needed CC/LD options checking and workarounds, maybe even
optimizations, if available. Traking of exported out kconfig sysmbols,
making sure nothing leaks, so no problems with dependency, if usage of
exports is agreed (e.g. usb and network). Local symbols must apear only
inside directory. This will simplyfy and speed up pre-build process. In
such configurations Intel ...
