Writing an Operating System in Ada
in [ADA]
|
Prev: GNAT requires body of generic unit to be present at build?
Next: ASISEyes : show you the ASIS interpretation of an Ada source
From: Shark8 on 12 Jan 2010 17:50 On Jan 12, 3:39 pm, nobody <nob...(a)nowhere.com> wrote: > Shark8 wrote: > > The problem about having no I/O is that there are some file-formats > > which ARE sequential-in-nature as opposed to Random-access/Record-in- > > nature: Midi and Huffman encoding (actually MOST compression would > > fall here) are to examples off the top of my head. Or am I > > misunderstanding what you mean? > > That is just implementation details that should(can) be hidden from the > application code. Stick to the objects. Don't forget associations. Aren't associations rather trivial if we derive all files from some base tagged-type and use the tag as the type-identifier?
From: Shark8 on 12 Jan 2010 18:26 On Jan 12, 2:52 pm, Maciej Sobczak <see.my.homep...(a)gmail.com> wrote: > On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...(a)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.).
From: Leslie on 12 Jan 2010 22:38 Shark8 wrote: > On Jan 12, 2:41 am, "Dmitry A. Kazakov" > <mail...(a)dmitry-kazakov.de> wrote: >> On Mon, 11 Jan 2010 17:13:55 -0800 (PST), Shark8 wrote: >> > Anyway, I was wondering if anybody here would be interested >> > in such a project. >> >> If that will be a really new OS (not a UNIX clone), OO, >> portable, distributed etc, for interesting platforms like >> this: >> >> http://blog.makezine.com/archive/2009/08/scalable_open_source_computi... >> >> why not? >> >> -- >> Regards, >> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de > > You know that was a frustrating / discouraging thing to hear > almost everybody I talked to about wanting to write an OS say > something along the lines of "Why don't you just download the > sourcecode for Linux?"... I'm sorry folks, but I don't want to > be the OS equivalent of a 'script-kiddie'. > > One thing I find very annoying about the Unix/Linux mentality > is the "everything is a file" philosophy... coupled with the > C/C++-ism of simply assuming that a file read/write went well > and you're asking for trouble. {Yes, I know that you CAN check > to see if writing is successful or not in C/C++, but it goes > against most C/C++ programmer's sense of terseness/'beauty'... > the same one that makes no check on array-bounds.} </Rant> If possible, also, it would be nice to get away from the "root can do anything" paradigm, and its associated inherited privileges (crash a root-capable process and steal its privileges). It would be nice to see something more like the explicit privilege design used by CP in IBM's VM operating systems. As a side note, does anyone here remember the Intel iAPX432 processor, designed to execute Ada programs (almost) directly? Leslie
From: Georg Bauhaus on 13 Jan 2010 04:09 Dmitry A. Kazakov schrieb: > The problem is that we followed the wrong path for too long. All these > standards (XML to name one) are based on these flawed untyped file - "don't > care about the contents" model. There could be no return, maybe. The name "Don't care about the operations" model of file systems seems adequate because virtually all contemporary file systems and archive formats offer file type indication (via extended attributes). Only the C and Ada libraries typically do not make programmers aware of this fact.
From: Dmitry A. Kazakov on 13 Jan 2010 04:17
On Tue, 12 Jan 2010 13:52:40 -0800 (PST), Maciej Sobczak wrote: > On 12 Sty, 20:56, "Dmitry A. Kazakov" <mail...(a)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. Marshaling? In terms of ADT it is assignment. Create a local object of the type. Assign the remote object to it. Done. Provided you have the assignment defined. > Did I mention that you might want to move you whole hard drive to > another machine as well? :-) Did you try? What happens with a NTFS drive in a Linux system? Can you mount it as an ext4? This is not a question of objects or raw blocks. If the OS recognizes the pluggable component, there is no problem, if it does not there is a problem. Nothing prevents a portable design of persistent storage. Note that the file system itself is built on a layer of blocks and sectors. So if your argument worked, there would be no need for a file system. We would still read sectors and count drive heads... > There is a reason why none of the pure-OO-OS-let's-do-it-correctly > ever really took off. Yes. There are many reasons. For all there is no consistently designed OOPL, Ada included. Without MI, MD, tagged tasks, there is no chance to get it right. But the major problem is lack of any interest, since the market of operating system was burnt down to the ground. >> 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. Maybe. If we compared the computing power we had in i386 days with the power of a modern machine (that includes not only the CPUs but also all processors and micro controllers on board). Is this increase of power matched by what the software provides? I don't think it is. The "pragmatism" was, if you have a software problem, buy a new computer. That might be economically OK, but it still is bad for the software. In long term perspective we sooner or later will be forced to use computing resources more efficiently. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |