Re: [elysium-developers] IDE code

[Claus M. <cla...@ma...>]

> We could setup non-present pages and map those. Actually we could have
> the whole disk mapped in memory this way (Damm 32-bit addresses) with
> page-faults on access etc. I don't really know the issues here, so feel
> free to simply say "Nope." ;) All those page-faults could kill the speed
> thou.

On the subject of 32 versus 64 bit CPU's: What *are* we going to do? Since
the Elysium kernel's behaviour is heavily dependent on the machine of which
it runs (or is it? Are there so few abstraction, they mainly will be
identical on most computers? I'm not the most hardware-minded here, so I'd
like to know how challenging porting Elysium will be. What, if any, will the
changes in the specification for the kernel be on a 64-bit system?), at
least when it comes to 32 versus 64 bits, what will we do when Itanium hits
the shelves later this year? As far as I see, mapping all physical memory in
one address space seems a very viable abstraction, even though it can be
argued that it's not the most exo-ish way of doing it (*I* think it is. I
just said it could be argued that it wasn't).

As far as I see, there are two ways about it: Either we choose to implement
a 64-bit-style block server mapping the hard drive into physical memory and
say "up yo*rs" to those old-fashioned 32-bit machines (like mine. Just
bought a dual-celery, overclocked and everything and it's already
oldfashioned. There's computers for you. Why, when you get right down to it,
really bother?). The other alternative is of course to write a 32-bit server
first, wait until the 64-bit market matures and then launch a 64-bit version
then.

The first choise presents the obvious problem that none of us has (or for
some time will have) an Itanium. The kernel would also have to be re-written
and/or recompiled for the Itanium. This option is of course less severe if
the changes in the specification for the Elysium kernel are miniscule, but I
know too little about those things. In all circumstances we would need a
temporary 32-bit server for use with our own machines.

The other option rather ties us to the Pentium-style processors (or at least
32-bit processors) for some time. We could of course easily replace the
servers that are affected then the 64-bit processors come, but how many will
they be? As we get higher and higher up in the system hierachy, the
abstractions should make the higher system servers immune to such changes.
But I rather expect the hierachy on our system to be rather flat, resulting
in the possibly that nearly all servers and libraries have to be rewritten
or altered in some way.

Neither of these options are very appealing, IMHO. I have a suggestion,
which might make me very unpopular: Could we just use 64-bit adresses now on
the 32-bit processors, perhaps by making adresses lower than
0x000000100000000 memory-adresses and addresses larger than that
block-device addresses? It would be introducing an abstraction (sort of.
What we really do is expand the address space and pretend it's larger than
it is, but what the hell), but if it proves an effective, non-restricting
and above all visionary abstraction, I feel that it at least should be
considered.

Looking very much forward to your comments,

- xmentor

PS.
  The first drafts of the graphics window system layout will be posted in
about a week. Designing higher-level systems under Elysium is fun!