This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Configuring for bare hw ia32 PC's

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 specific kernel.

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:

Step 1.

 somedevice.C file - needs some 'struct foo' definition.
 somedevice.C file - needs some 'enum bar' definition.
	These are used in some device ioctl() call.

Step 2.

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.

Step 3.

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

Step 4.

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 other places.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]