RE: another proposed crosstool project

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

[Sorry for the re-send. The crossgcc mail agent tagged the original as
spam for reasons I do not understand.]

On Sun, 2007-05-06 at 19:31 +0100, Dave Korn wrote:
> > I think the real issue we are facing is missing abstraction boundaries
> > in the library implementations. It's hard to know what to do about that
> > in the face of uncooperative maintainers. The real issue, I think, is
> > that most of the library efforts are no longer trying to support any
> > non-UNIX target, and in consequence they have given up on the notion of
> > an OS abstraction layer in their library designs.
> 
>   I don't think that's entirely accurate.  They /do/ have an "OS abstraction
> layer", and it conforms to POSIX.

It isn't an OS abstraction layer if it only supports a single OS.

>   If you want to run glibc or stdlibc++-v3 on
> a non-POSIX system, can you not just build a POSIX-compatibility shim layer?

No. If our application domain could tolerate the architecturally
intrinsic instability and unreliability of POSIX, we would have either
built a POSIX system or used Linux. We deal in applications where
millions of dollars or human lives may be lost **every time** we crash.

For example: POSIX-compliance imposes requirements that would prevent us
from guaranteeing a deadlock-free application runtime environment. It
doesn't really matter whether that misfeature is implemented in our
nucleus or in a POSIX compatibility shim. The patient is still dead if
our device messes up, and their family and children will not care.

> Would switching to some completely new and non-standard OS interface spec
> really bring much by the way of benefits?

Yes. Without question POSIX is a fatal design choice for us. Literally.


shap


--
For unsubscribe information see http://sourceware.org/lists.html#faq