This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: Configuring for bare hw ia32 PC's
On Mon, 2008-05-12 at 20:44 -0400, duane ellis wrote:
> 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')
Duane:
In concept, we agree about most of this. If you look at the C library
standard, you will find that the following headers are provided in a
freestanding implementation:
float.h
limits.h
stdarg.h
stddef.h
iso646.h
stdbool.h
stdint.h
These specify typedefs of integral sizes, elements necessary for the
compiler, MIN/MAX constants, and so forth. As a practical matter, the
file inttypes.h is a trivial extension of stdint.h, and is also safe.
If you look, you will discover that all of these are provided by GCC, so
there is really no good reason to replicate them. There *is* some risk
of file version drift if you *do* replicate them.
Just for amusement, I just went and checked the Coyotos tree, and found
(with relief) that yes, we really do limit ourselves to these
dependencies -- with the exception of some application level header
files where it is really okay to rely on libc. We do rely on inttypes.h,
and I'm going to file a low priority bug on 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.
In practice this is a bit too strong. There is a necessary incestuous
relationship between the kernel and the compiler where the freestanding
header files are concerned.
But with that qualifier, I agree with you.
> Using that logic, the *KERNEL* would effectively supply a "libgloss" and
> NEWLIB should not.
Historically, UNIX System V actually did separate libsys.so (the system
call stub library) from libc.so, which is the moral equivalent of what
you are suggesting. For a variety of reasons, the later convention has
been to re-fold the libsys stubs into libc. In practice, the set of
system calls is stable enough that this has not been a problem, and
there are significant performance advantages if this is done, but I
still tend to think that it was a bad idea.
In some cases there may need to be an extra level of header synthesis
involved if, for example, the kernel interface is specified by IDL
rather than C headers. This is how Coyotos does things. I don't think
that this violates the spirit of your view.
> 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)
Yes. This is why I believe that the merge of libc and libsys in linux
was a mistake.
> 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.
Actually, newlib is agnostic on this. It is possible to provide a
system-dependent subdirectory that implements system calls, and skip the
build of libgloss.a
Part of the problem is that the split between the system call stubs and
the rest of libc really isn't as clean as you are trying to make it
sound. In particular, the system call stubs rely on the native thread
mechanism, which in turn tends to rely on assert, which in turn tends to
rely on stdio. And the responsibility for threading gets tied up in
application-level symbol resolution, so ld.so must also be in on the
joke.
I will say that newlib does a pretty good job of keeping the boundary
clean, mainly by trying very hard to follow the model that you advocate.
> But why are things the way they are? Enter the pot roast or ham butt
> problem, There are many versions of this story
Fun stories, but I think this is only part of the explanation for what
is going on here. The problem is that a production quality system call
stub library requires a good bit more functionality than any of us would
prefer -- primarily because of threading and error handling.
I'm not disagreeing with your design as a concept. In an ideal world it
would be really nice if things worked out this cleanly. The problem is
that we don't live in an ideal world, and there are several components
that have valid roles in defining the bottom layer of the application
run-time environment.
We would not, for example, want the kernel to define ld.so or its
interfaces, nor should the kernel have any knowledge of thread-local
symbol resolution.
shap