Configuring for bare hw ia32 PC's

[duane ellis]

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

http://www.ted.com/index.php/talks/view/id/161
[a fascinating talk about redefining what a dictionary is]

http://mitmoi.blogspot.com/2006/11/pot-roast-story.html

http://www.tween-the-shadows.com/magick/pot_roast.html

---

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 -

http://gcc.gnu.org/ml/gcc/1999-06n/msg00729.html

6 years later - Still exists - (look for inhibit_libc)

http://www.diy-linux.org/pipermail/diy-linux-dev/2005-July/000575.html

Just recently GCC *finally* accepted the patch to make cross-gcc easier.

Meanwhile, we are all happily making pot roast & ham butt.

-Duane.