Re: Writing an Operating System in Ada

[Shark8 <onewingedshark@gmail.com>]

On Jan 12, 2:52 pm, Maciej Sobczak <see.my.homep...@gmail.com> wrote:
> On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > There should be no file system at all. If you have objects, I mean if you
> > do have them consistently all the way, then you do not need files. Make
> > objects persistent in the corresponding device, that gives you all
> > functionality of any file. No I/O is ever needed. Map the object into the
> > memory, call its operations, what else any program would have to do?
>
> Interact with other systems? You know, you might want to sometimes
> move your "persistent objects" to another machine.
>
> Did I mention that you might want to move you whole hard drive to
> another machine as well? :-)

True, systems may be fairly static: like my old desktop. Or they may
be fairly dynamic, being updated/improved regularly. It would be
pretty dumb to force someone's data to be bound to a certain system,
like certain DRM-pilious companies. While we can be fairly certain
that many things will be the same, such as the CPU's family, to
completely disregard such exceptional (or regular in the case of some
distributed systems) circumstances is valid only in academia or some
project where you are GUARANTEED to have only a single configuration [-
set] to deal with.

Gaming platforms come to mind there, as well as Macs where the company
controls hardware.

> There is a reason why none of the pure-OO-OS-let's-do-it-correctly
> ever really took off.

I think you're getting a valid point there. It makes more sense to me
to have file-objects derived from some stream-type and then having
that stream directed [and possibly transformed, as need be] by the
filesystem-object to the drive. {A FS may be of the opposite endianess
than the system which is accessing the data, this is a non-issue if it
is ALWAYS read & written the same way BUT if you were to port the
drive to a system with the same endianness the reading and writing
would be mixed-up.}

IE - in the high-level world Write(Integer) and Read(Integer) are
completely safe... but if another system were to read/write the data
in the opposite endianess bad things happen.

> > The problem is that we followed the wrong path for too long.
>
> There is nothing wrong with that path, as it happens to be very
> pragmatic.

The main problem is, I think, the API-standard of keying, to borrow
from databases, on the (Location, Name) Tuple. If we consider the name
of a file as a mutable attribute then we must use some other criteria
for identifying files. (ie it makes little sense to have a file become
invalid because you used the standard 'rename' command.) For a local
system we could use the GUID of a 64-bit word, however this system
would not work well for distributed/remote/networked systems because,
in the absence of proper communication some other Index may be added
by two different systems trying to ID a certain file. I would suggest
using a vector of hashes to key [UUID] File-ID across a network, say:
(MD5, SHA1, XOR-32). This would have the drawback of generating a new
ID every time the file is updated... though that could be overcome by
allowing the OS to track such changes with versioning or redirects or
somesuch.

GUID : Globally Unique IDentifier. (Longitude, Latitude) is a GUID.
UUID : Universally Unique IDentifier. (Longitude, Latitude) is NOT a
UUID because different planets have the same (Long., Lat.) tuple, in
order to be a UUID we would have to indicate which planet we are
talking about, like this: (Name, Long., Lat.).