newbie questions

[Wulf Hofbauer]

Hi again,

On Tue, Oct 08, 2002 at 06:51:35AM +0200, Ralf Corsepius wrote:
> Am Die, 2002-10-08 um 04.00 schrieb Till Straumann:
> RTEMS 4.5.0 is ancient and so are its docs ;)

What would be the best version to get started with RTEMS? 4.5.0
is the most recent stable version I found.
My main focus is on getting an initial version of my application
up and running before I can think about hacking development
versions.

> gcc-3.2 and binutils-2.13 probably won't work with rtems-4.5.0.

But... WHY? As long as you can translate the C and assembly
routines and link them, it shouldn't really matter, no? Gcc and
binutils aren't THAT buggy either ...

Is there a real problem with the toolchain, or is it simply the
building procedure that is so highly version dependent?

> 2. There exists a bootstrap/"hen and egg" problem between newlib, RTEMS
> and gcc, which is difficult to solve: RTEMS implements the lowlevel
> OS-related parts of libc, newlib implements a set of general mid-level
> parts of libc, RTEMS implements another set of these mid-level parts and
> even worse, gcc also implements a certain set of libc-related parts
> (libgcc rsp. libgcc_s).

This sounds pretty messy to me (isn't that a maintainance
nightmare?). To me, it looks like an exercise in frustration
to get all the specific tools + patches together in order 
to build the kernel (before even doing anything useful).
It's definitely a deterrent factor to using RTEMS.

> > Hmm I wouldn't expect a clean separation between the layers
> > but rather quite some amount of glue...
> Exactly, this is one essental part core of the problem. But, ... RTEMS
> has evolved, newlib has evolved, gcc has evolved and binutils has
> evolved => "the glue" is in permanent motion.

I understand glue is needed to interface newlib to RTEMS (and
that glue would then be part of newlib, not RTEMS), but I
fail to see why newlib is required to build RTEMS itself.
For applications on top of RTEMS, a C library can be useful,
but why for the kernel? And why does it have to be newlib?

> > Well, AFAIK, RTEMS implements parts of the C library (e.g.
> > lowlevel-malloc, reentrancy, ...). Hence, you'd expect it to
> > certainly depend on the newlibc headers.

Newlib glue code may depend on the RTEMS headers, but I don't see
why it should be the other way round.

> This is not any different from other OSes, eg. Linux where interfacing
> glibc2 and gcc is a similar problem (You might have heared about the "To
> whom does /usr/include/[linux|asm] (aka. the kernel-headers) belong
> issue).

Well, AFAIK Linux doesn't depend on any C library at all. The
kernel is self-contained (as it should be), and libc is built on
top if it is needed. You can choose which C library you want, if
any.

> Try to build a linux from scratch and from sources only (without
> having a linux c-compiler or glibc binary, you will encounter the same
> issues then.

Linux doesn't limit me to a specifically patched rigidly specified
version of gcc or binutils for one ...

I'm still hoping to be able to use RTEMS, but so far the
"out-of-the box experience" has been less than encouraging.
For an OS hacker, that may be appealing, but I have a real world
instrumentation problem to solve ...

- Wulf