Configuring for bare hw ia32 PC's
Tue May 13 15:45:00 GMT 2008
shap> --nostding is too strong, because you want to be able
shap> to get things like inttypes.h.
That is exactly my point about kernels needing to be 100% monolithic and
self contained source.
The question is 'ownership' - if a header file needs to change, who owns
the change, and how that change flows through the development process.
Some things should come from the compiler (ie: limits.h)
(not sure about 'inttypes.h')
It is my strong belief that:
If a kernel needs some special header file then that header file should
be *IN* the kernel source tree it self, and the kernel source tree
should export to a 'user environment' area - however defines by that
ie: The kernel is the root of all evil, and from it all evil grows.
Using that logic, the *KERNEL* would effectively supply a "libgloss" and
NEWLIB should not.
A simular problem occurs with the current linux system and glibc. When a
new kernel feature appears - and one must wait for support in glibc, or
directly do the syscall your self (messy)
I'll use a kernel device driver as an example. I view it like this:
somedevice.C file - needs some 'struct foo' definition.
somedevice.C file - needs some 'enum bar' definition.
These are used in some device ioctl() call.
These are found in '#include <userspace/something.h>' Not in #include
<kernelspace/something.h> because the use side needs access to these
special device driver structs and enums.
The kernel driver code can safely #include the private
<userspace/something.h> file because it is located in an internal kernel
directory, and does not have "*.h" (the rest of the world)
Eventually, the kerenel publishes the #include <userspace/something.h>
in a public place for the world to make use of.
The user side of the syscall needs some low level function just above
the multiplexed syscall interface. Just how one defines that is up to
the OS impliementor.
In effect, I believe every 'kernel component' should export it's own
little "how to use my features" library and header file.
In effect, these would be open(), close(), read(), write(), etc.
shap> [snip - speaking about how they integrated newlib into Coyotos]
shap> For reasons having to do with packaging, we elected to do neither.
shap> We instead configured an *empty* libgloss and supplied a
shap> libgloss replacement library from our OS source tree.
Another example: USB-Gadget and others
Right above the 'low level functions' is the "standard c library" -
functions like "fopen()" = aka: 'glibc'.
shap> For newlib itself, the intended "theory of operation"
shap> is to define a short list of required system calls,
shap> either by adding a target OS config section in the
shap> newlib tree or by defining them in libgloss.
Understanding the reason behind that theory is important.
Like in coyotos - it is a packaging problem.
But why are things the way they are? Enter the pot roast or ham butt
problem, There are many versions of this story
[a fascinating talk about redefining what a dictionary is]
Like all things GNU - they start as a replacement, and that mentality
has remained forever... GCC and GLIBC, and ... where always a
replacement for some standard something. That thinking means: This sort
of stuff lives in the *LIBRARY* - not the kernel.
Newlib is exactly that too - it lives on top of cygwin, linux, and many
GCC suffered from this problem for *YEARS* -
From 1999 -
6 years later - Still exists - (look for inhibit_libc)
Just recently GCC *finally* accepted the patch to make cross-gcc easier.
Meanwhile, we are all happily making pot roast & ham butt.
More information about the Newlib