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: Tero Koskinen on 12 Jan 2010 14:07 On Tue, 12 Jan 2010 16:21:23 +0000 Colin Paul Gloster wrote: > On Mon, 11 Jan 2010, Leslie wrote: > > |-----------------------------------------------------------------------| > |"Shark8 wrote: | > | | > |> I was wondering if there would be any interest in coding up an | > |> OS in Ada. .... > |language to user for writing an OS. I'm not yet proficient in | > |Ada, but would be interested in contributing what I can. | > | | > |Leslie" | > |-----------------------------------------------------------------------| > > If the two of you are willing to implement an operating system in Ada > then proceed and succeed! I wish you well. However, every few months > or years hobbyists' projects for volunteers to develop an operating > system in Ada not aimed at embedded targets have been proposed on this > newsgroup without ever amounting to anything. If creating i386/amd64 OS is too hard or big task, another alternative is to target some embedded board. The easiest option is probably AVR-Ada[1] and Arduino[2] or some other AVR board. AVR-Ada works (almost) out of the box on many platforms and Arduino board costs around 20 euros. > Regards, > Colin Paul Gloster -- Tero Koskinen - http://iki.fi/tero.koskinen/ [1] http://sf.net/projects/avr-ada [2] http://www.arduino.cc/
From: Dmitry A. Kazakov on 12 Jan 2010 14:56 On Tue, 12 Jan 2010 09:37:11 -0800 (PST), 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? >> > 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> Wow, can you read minds? (:-)) I wrote about something like that many many years ago. Yes, "everything is a file", "fore every possible job is a utility", "every action is a process" is a pest of UNIX. > Now the idea that everything [system-wise] is an object is much more > appealing to me. World-wise (a modern OS must be distributed) > Objects are a very natural way to [generically] model > hardware: a display has a running-resolution, available resolutions, > OpenGL/DirectX compatibility, etc. It could even be engineered in such > a way that every device-object 'knows' how to write code for its > device and that code is JIT-compiled for the specific system. > (Example: A PCI-card can be inserted unto a system-board with a SPARC > processor, or one with an AMD processor, the two different endian-ness > but the card is the same for both, so it stands to reason that a > device-object [device-driver] could be written in a high-level manner > abstracting out the low-level... probably by having the aforementioned > JIT which is linked to the CPU's device-object tell that object to > output the codes for the PCI-card-object.) > > Having such a system means that we could support disparate > architectures by having base-CPU objects & the high-level driver- > objects on a bootable CD with a VM such as DOTNET or JVM and > 'installing the OS' would be compiling it for that HW-setup. The > downside to how I'm describing it is that it sounds a little too Unix- > y. > > Using the Java-style interfaces we could have a file-system interface > which would allow the OS to use any FS which was implemented in an > object using said interface. 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? 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Shark8 on 12 Jan 2010 16:21 > Wow, can you read minds? (:-)) I've been accused of it... but those are merely accusations. ;) > > Now the idea that everything [system-wise] is an object is much more > > appealing to me. > > World-wise (a modern OS must be distributed) I'm not overly-sure about that. It still makes sense, especially from a security-standpoint, to have systems which are isolated. But on the whole, yes it needs to have that sort of extensibility. I think the best idea would be to metaphorically "borrow recursion" for the distribution-design such that a single computer is the 'base case'. > > Having such a system means that we could support disparate > > architectures by having base-CPU objects & the high-level driver- > > objects on a bootable CD with a VM such as DOTNET or JVM and > > 'installing the OS' would be compiling it for that HW-setup. The > > downside to how I'm describing it is that it sounds a little too Unix- > > y. > > > Using the Java-style interfaces we could have a file-system interface > > which would allow the OS to use any FS which was implemented in an > > object using said interface. > > 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? I agree for the most part and would want Files to be full objects themselves... and since objects 'know' their own type so would these files. Perhaps having files be their own objects with a mix-in of a stream would be a wiser choice... or they could all be descended from an abstract-stream-object. {Files SHOULD be typed, absolutely.} 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? > 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. XML is ugly. Really ugly. EA's IFF was/is more interesting. And with Ada'a inherent ability to read/write most types directly to/from a stream it XML would be fairly unnecessary. The original purpose for XML being: "describe a type-layout" (the DTD) now everything can use that layout (basically an instance of that record)!
From: Maciej Sobczak on 12 Jan 2010 16:52 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? :-) There is a reason why none of the pure-OO-OS-let's-do-it-correctly ever really took off. > 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. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada
From: nobody on 12 Jan 2010 17:39
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. |