Re: An OS in Ada, why not RTEMS ?

[nickroberts@ukf.net (Nick Roberts)]

On Sun, 28 Apr 2002 07:45:49 GMT, James Ross <rem.jr@rem.webross.com>
strongly typed:

>- As for the ultimate goal of an OS written in Ada -- I agree with the
>AdaOS folks; To end up with a "complete OS".  Just to have a real-time
>kernel written in Ada,  even though might be appealing to the embedded
>programmers, is by itself of little use to me personally.  However, I
>agree if there was one, it might generate enough interest to turn into
>more than just that.
>
>- I can't help from constantly thinking that any work from scratch on
>a project of this scope is an exercise of re-inventing the wheel.  

I am getting near to having a 'design document' for a microkernel ready
(but still not complete) to post onto the AdaOS web site. You wouldn't
believe the changes it has been through!

It is not entirely an exercise in reinventing the wheel. It has certain
features that I have not seen in any other microkernel (certain deadlock
avoidance and locking features). I believe these features to be vital (for
the purposes of a distributed general-purpose OS).

RTEMS is only a real-time kernel (no doubt a very good one). But it has no
security features, and misses many other features that (I believe) an AdaOS
kernel must have.

>- To begin with the boot process and progress through all the stages
>of OS design starting with absolutely nothing is a monumental task!

The boot process itself is nearly trivial. Even the microkernel is a
relatively simple component. The 'upper' levels of the OS will not be so
trivial, but I believe that when we get to those levels it will be possible
to work 'in parallel' and so to achieve a much higher level of
productivity.

>Hence I believe the reason there has been no *apparent* progress on
>the AdaOS project. 

That is correct. It is like a few ants beginning the process of building an
anthill. At first, there is apparently nothing to see.

>- Then there is the GNAT raw binary executable images / linker
>problems / issues.  Even though not insurmountable, it's a pretty big
>obstacle.  Perhaps the GNAT Professional product has direct support
>for creating raw binary executables that support the run-time and all
>the Ada constructs without any dependence on an OS (I.e. an embedded
>RT target).  But this does not seem to be the case with the free GNAT
>version. It seems to use free GNAT, you would need to support either
>ELF, or PE right of the bat in your new OS and be willing to do some
>hacking on the GNAT run time sources as well.

I would be delighted if someone were to take on the work of modifying GNAT
and/or GCC enough to make it usable to build all the components of an OS in
Ada.

However, one of my key personal objectives in starting the AdaOS project
was to create not just a new microkernel, but a new Ada compiler which
would specifically target this microkernel. This is ambition enough, so I
feel I cannot devote any time to modifying GNAT at this stage.

>I have come full circle in my thinking and believe it would be simpler
>to start with say either FreeBSD or Linux and gradually "craft" it
>into an "Ada OS".  You would not need to hack the free GNAT toolset.
>Of the many advantages to this approach, one of them would be that
>even if the goal is never reached, you might end up with some really
>cool add-ons and/or extensions to an existing OS. Isn't this basically
>what Apple has done with OS X?

Maybe the AdaOS project should go this way, or some other alternative
route. It would have to do so without me, but with a membership of nearly
50 now (I think), that surely wouldn't be a problem. I'm going to start
discussing things like this with the membership soon.

>At this point, I have about decided to chose a different project to
>learn Ada 95 on.  To build an OS from scratch might be just a bit over
>my head :)

Well there's no reason for you not to remain an AdaOS member, James. I've
no doubt that at some point in the future you will be in a position to
write code for us, and we will be in a position to ask for it. It might be
a while away yet, though!

-- 
Nick Roberts