On Mon, Mar 14, 2005 at 01:54:19AM +0000, Charles Goodwin wrote:
> From a birds-eye-spectator-view of things, I'd have to say I found the
> EROS idea more attractive. EROS seems more aligned with the goals of
> Uuu and it also is much less exposed which is both a good and a bad
> thing. (Good in that it would make Uuu not yet-another-linux-variation
> and bad in that it's less tested.) However, what is attractive and what
> is practical are frequently different things.
>
> Well, that's yet another opinion for you to digest. *shrugs*
>
> - Charlie
Uuu is not a linux variant. It's an OS that can run _on_ linux, and
hopefully, any other posix compliant system. How the hardware is
accessed, be it by 'in' and 'out' instructions, or by standard C
functions, is irrelevant at all but the lowest layers. The point of
using posix is to have a stable, mature, easilly accessible, and widely
available platform for Uuu to run. EROS might be stable, but I would
venture a guess that it's driver support is nowhere near that of linux
or darwin, and it is definately not as available.
I did not think that the hardest part of porting uuu to posix would be
explaining the concept. The problem is some people are stuck on this
hierarchy:
hardware
|
OS
|
+----+----+----+----+
| | | | |
app app app app application
|
+--+--+
f f functions
When really the only hierarchy we are forced to use is this:
hardware
|
program
A CPU doesn't know there is an OS, which runs applications, which are
composed of functions. It just knows there is a program to run, composed
of a sequence of instructions. How we name and arrange parts of the
program is totally irrelevant to what the computer has been programmed
to do.
An OS when properly designed does not require that to access the disk
controller it must manipulate IO ports around 0x1f0 and 0x3f6. It could
just as well use any other interface, such as a posix compliant C
library, which calls linux syscalls, which manipulates IO ports. This is
not unlikely running Uuu directly on hardware that is not IBM PC
compatible, where the instructions to access the disk controller might
be entirely different, or there might be a different type of controller.
The goal is to eventually have Uuu running directly on hardware for best
performance. Using "posix" as "hardware" allows development to skip
boring driver development that doesn't really contribute anything new to
the OS scene. Furthermore, linux is the platform used by most uuu
developers, and those who do not have linux have access to a posix
system as cygwin on windows or darwin on mac. This makes development
many times faster since there is no rebooting involved.
An EROS port is certainly welcome if someone wishes to try it. Indeed it
does offer an orthogonal persistence mechanism which could be useful for
Unununium. However, it is neither our final goal, nor does it satify the
requirement of device driver support nor is it as accessible.
|
