Re: Confirming porting strategy

["Jonathan S. Shapiro" <shap at eros-os dot org>]

On Fri, 2005-09-23 at 14:16 -0400, Daniel Jacobowitz wrote:
> On Fri, Sep 23, 2005 at 02:05:31PM -0400, Jonathan S. Shapiro wrote:
> > I want to outline our current porting strategy. I suspect it is generic,
> > but perhaps we have missed something that someone will be able to point
> > out and save us a bunch of time.
> 
> It's not generic; if I'm understanding you right, you've already got an
> OS and a system libc.  Almost all glibc ports are done to systems
> without an existing libc.  So this:
> 
> >   1. All system call stubs return ENOSYS. This is turning out to be
> >      pretty easy, since it is what the generic/ tree does.
> 
> is a complete non-starter; in fact, I'd do it the other way around, and
> have the system calls first.  Higher level libc behavior is much
> simpler to analyze and debug.

I'm not sure what you mean by "an OS and a system libc". We do not, at
the moment, have any implementation of any POSIX system call anywhere.
Let me pop up one level of abstraction to explain what is going on.

We're actually in the OS bringup stage, and we're borrowing a lot from
the EROS code (which used newlib). In general, the OS shouldn't depend
on libc, but we do permit the OS to include certain header files that
might be considered "non-hosted". In particular, we include stdint.h and
limits.h in OS source.

Since we want to use glibc, this made it convenient to try to get a
naive build of glibc going early. It let me validate the cross-build
options. I realize that we could settle for header file installation and
I'm about ready to do that if I can't get a build pretty soon.

So my overall approach here is:

  do a cross-tools bringup, including a completely lame glibc port
  bring up our kernel
  go back and do a more complete glibc port

There is a larger issue with system calls here: Coyotos isn't a POSIX
system at all, and for the native-hosted Coyotos glibc we have to make
some challenging design decisions about how much of the POSIX API needs
to be removed from glibc and how much can sensibly be supported and what
are the pros/cons for compatibility with existing code. For example: it
is an open question whether native-mode Coyotos apps even have
stdin/stdout/stderr. In consequence, it is an open question whether the
native-mode libc should include STDIO **at all**. In practice, I think
there are compelling reasons to keep STDIO, but we *definitely* need to
get rid of all support for (and use of) the signal() family of
functionality.

So the situation we are in is that deciding what to do at the syscall
layer in glibc is going to involve some fundamental architecture
decisions that need to be deferred for a while. In the interim, we don't
plan to use anything from GLIBC more complicated than memcpy().

In fact, if glibc had provision for a non-hosted minimal implementation,
I'ld be trying to build that at the moment rather than port the library
as a whole. For our really early work all I really need/want is some
innocuous headers, the memcpy() family, and malloc/free (which we need
to do native anyway).

Thus: our current bringup strategy.

It occurs to me that it might make more sense -- and have broader use in
the community -- to do a port intended for non-hosted platforms.

shap