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 13 Jan 2010 15:37 > > I was wondering if there would be any interest in coding up an OS in > > Ada. I don't mean taking an existing codebase and rewriting/converting > > it to Ada, but implementing it from the ground up. [SNIP!] > > > > Anyway, I was wondering if anybody here would be interested in such a > > project. > > Me too, I wrote a "hello world" kernel in Ada ages ago and posted it > up onto my blog site:http://www.archeia.com- it's a tad slow though > so will be moving my site over to a new one when I get around to it :D > > I'll also be getting back to the OS (when I get around to it :D). > > Luke. Nifty. I came across your blog a while back as I was looking up some Ada 2005 features (thank you for your explanation, in particular); it's pretty good, IMO. If you'd like to pop me an e-mail or IM and talk-shop about OS/OS-design I'd be more than happy to do so. {The same goes for everyone else who's interested.}
From: Dmitry A. Kazakov on 13 Jan 2010 15:55 On Wed, 13 Jan 2010 12:20:54 -0800 (PST), Shark8 wrote: >>> 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. > > What happens when the network is disrupted in the middle of an > assignment though? An exception (in Ada it is Program_Error, which must be changed. This is one of Ada's problems, which make it less suitable for designing an OO OS. Initialization, Finalization and Assignment do not roll back) > Is the assignment atomic? In the same way Adjust is. > If it's a large store of > data is it resumable, or does having a large file on a flaky server > doom you to never being able to retrieve the data? If you have no CPU fan, can you run the computer? These are silly questions. There are certain preconditions for certain services to work. You cannot access remote objects when the network is down. So what? >>> 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? > > Ah, here you're confusing "is a" and "has a" because the drive itself > is NOT a file_system, but it may have one [or a part of one]. You can > think of the file system as a format-for-the-data. So, like some > people have done with compression/encryption and made an abstract base > to derive from we can do the same with file-systems. I don't see how this is related to the point. Both NTFS and ext4 are file systems, which by no way helped to access one where only another is supported. The same is true for any type of the objects. In order to move a piece of memory containing an object from one system to another, the representation of the object there must be understood. >> This is not a question of objects or raw blocks. If the OS recognizes the >> pluggable component, there is no problem, > > Nope. The OS can detect a perfect & compatible drive and yet be > mystified by its contents because it doesn't understand how to read > it. What was recognized then? > If the drive is a dictionary, the entries are the particular files/ > directories/objects thereon, but it is pretty useless to give someone > a dictionary in a language they can't read. No, it only means that the object called dictionary is supported and other objects called articles are not. The same error was made by the relational data bases, they understand the structure of relations (relational algebra), but do not do the elements of the tuples. >> 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... > > Oh please don't say that the best way to reference disk-data is by > (sector, block) direct access... I'd prefer to have my hardware a > little more intelligent than that, and have my CPU available for > things other than calculating location-offsets. It is the hardware to determine how low the abstraction can be. No lower than 0. The upper bound does not exist. If the argument is that no abstraction is needed, here is the device controller for you. Enjoy it. Otherwise, one have to argue why read/write is high enough and "read text buffer line" is too high. Obviously both are not. >>> 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. > > Ada is one of the most consistently designed languages I've come > across {LISP is another}, so if your argument is valid it should be > more doable in such language[s] than in other languages. Agreed. >> Without MI, MD, tagged tasks, there is no chance to get >> it right. > > If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005 > interfaces handle that pretty well. There shall be no interfaces at all. Ada 95 had everything needed, i.e. abstract types. Introducing interfaces in Ada 2005 was a huge mistake. > If MD is multiple dispatch then we're talking about something that > simply explodes combinatorically-speaking: Say we have a multi- > dispatch procedure with two dispatching parameters [Letter and > Number], ok? Now, if we have two versions of each of those in the > classes we get something like: > (A,1) > (A,2) > (B,1) > (B,2) Yes. Let you have printer devices and shapes. This is a classical example of MD. Yes, it explodes. That is the law of nature. There is nothing to do about it, with MD support or without it, you have these combinations, you have to handle them. MD does not solve this, it merely provides an infrastructure helping you to solve this. No more, no less. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Shark8 on 13 Jan 2010 17:50 > > If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005 > > interfaces handle that pretty well. > > There shall be no interfaces at all. Ada 95 had everything needed, i.e. > abstract types. Introducing interfaces in Ada 2005 was a huge mistake. Why do you say that? I see them as just being a contract for functions/ procedures that some object must provide, and in that sense there is no reason why an actual object-class cannot agree to one or more of these 'contracts'. One nice thing Delphi did was to allow an interface to be implemented by a field of the class, they called this "interface delegation" and looked something like this: Type TExample = Class(TObject, IDelegated) private DelegationField : TSomeDelegatedObject; public property Delagator : TSomeDelegatedObject read DelegationField write DelegationField implements IDelegated; end; //Example I suppose you could call it 'subcontracting'. > >> 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. > > > What happens when the network is disrupted in the middle of an > > assignment though? > > An exception Good point. > (in Ada it is Program_Error, which must be changed. This is one of Ada's > problems, which make it less suitable for designing an OO OS. > Initialization, Finalization and Assignment do not roll back) > > > Is the assignment atomic? > > In the same way Adjust is. > > > If it's a large store of > > data is it resumable, or does having a large file on a flaky server > > doom you to never being able to retrieve the data? > > If you have no CPU fan, can you run the computer? These are silly > questions. There are certain preconditions for certain services to work. > You cannot access remote objects when the network is down. So what? That depends if the hardware requires it, older system boards didn't have the power-supply coupled to the fan. And there are plenty of [small] system-boards that don't have fans, like the HC11 I played with. So, I suppose the best answer would be: "It's a matter of design." > > >>> 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? > > > Ah, here you're confusing "is a" and "has a" because the drive itself > > is NOT a file_system, but it may have one [or a part of one]. You can > > think of the file system as a format-for-the-data. So, like some > > people have done with compression/encryption and made an abstract base > > to derive from we can do the same with file-systems. > > I don't see how this is related to the point. Both NTFS and ext4 are file > systems, which by no way helped to access one where only another is > supported. The same is true for any type of the objects. In order to move a > piece of memory containing an object from one system to another, the > representation of the object there must be understood. > > >> This is not a question of objects or raw blocks. If the OS recognizes the > >> pluggable component, there is no problem, > > > Nope. The OS can detect a perfect & compatible drive and yet be > > mystified by its contents because it doesn't understand how to read > > it. > > What was recognized then? The physical drive itself.... it has to be recognized in order to get the "do you want to format?"-style message in the first place. > > > If the drive is a dictionary, the entries are the particular files/ > > directories/objects thereon, but it is pretty useless to give someone > > a dictionary in a language they can't read. > > No, it only means that the object called dictionary is supported and other > objects called articles are not. The same error was made by the relational > data bases, they understand the structure of relations (relational > algebra), but do not do the elements of the tuples. I think we have a failure-to-communicate here. I agree that relational algebra [blindly] works on tuples w/o knowing about the contents... that is in a sort of abstract fashion. If we use metaphor/allegory for the data-system [hard-drive, FS, data] would you agree that it could be likened to the following? The hard-drive is like unto a library containing books. The books of that library are like unto the data/files. The FS is like unto the indexing system (alphabetically by title, alphabetically by author, dewy-decimal, etc) coupled with the methodology for storing the 'books' (are they in boxes, on shelves, in a pile, etc). Can we both agree on this? > >> 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... > > > Oh please don't say that the best way to reference disk-data is by > > (sector, block) direct access... I'd prefer to have my hardware a > > little more intelligent than that, and have my CPU available for > > things other than calculating location-offsets. > > It is the hardware to determine how low the abstraction can be. No lower > than 0. The upper bound does not exist. If the argument is that no > abstraction is needed, here is the device controller for you. Enjoy it. > Otherwise, one have to argue why read/write is high enough and "read text > buffer line" is too high. Obviously both are not. I think I see what you're saying here, but abstraction _is_ one of the "big ideas" in computer science. If we're speaking of the hardware- interfaces we can see that there are some decided advantages to abstraction, take SCSI for example: SCSI devices transfer data on a higher-level than IDE by way of the SCSI-commands & the SCSI-protocol (which allows the host to reorder requests for optimal service). The only reason you need drivers for a SCSI card is so that SCSI-host and the OS can communicate. This is done in a manner very similar to Ada's spec/implementation divide. In our data-system/library example this would be like a professor telling TA "go get me such-and-such book". (The CPU playing the role of the professor & the SCSI-hose as the TA.) Perhaps the problem of miscommunication from earlier was due to misconstruing what I was trying to say regarding a "file-system- object" and its role; the role I'm thinking of is that of, in the aforementioned metaphor, would be the librarian... that is someone who knows how to read index-by-title/author/decimal (FAT32/ext4/Reiser/ etc) AND knows how to map that index into actual location (shelf/box/ etc). > >>> 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. > > > Ada is one of the most consistently designed languages I've come > > across {LISP is another}, so if your argument is valid it should be > > more doable in such language[s] than in other languages. > > Agreed. > > >> Without MI, MD, tagged tasks, there is no chance to get > >> it right. > > > > If MD is multiple dispatch then we're talking about something that > > simply explodes combinatorically-speaking: Say we have a multi- > > dispatch procedure with two dispatching parameters [Letter and > > Number], ok? Now, if we have two versions of each of those in the > > classes we get something like: > > (A,1) > > (A,2) > > (B,1) > > (B,2) > > Yes. Let you have printer devices and shapes. This is a classical example > of MD. Yes, it explodes. That is the law of nature. There is nothing to do > about it, with MD support or without it, you have these combinations, you > have to handle them. MD does not solve this, it merely provides an > infrastructure helping you to solve this. No more, no less. Ah, I think I was confusing the problem with that infrastructure then... But that does remind me, I was thinking it would be good to have PostScript as the display for the OS, unifying the visual display that way it would eliminate the need for printer drivers (assuming they're postscript printers) as well as providing a true WYSIWYG for print- preview (MS's print preview can be a bit... inaccurate), right?
From: Dmitry A. Kazakov on 14 Jan 2010 03:55 On Wed, 13 Jan 2010 14:50:50 -0800 (PST), Shark8 wrote: >>> If by MI you mean multiple inheritance I think the Java/Delphi/Ada2005 >>> interfaces handle that pretty well. >> >> There shall be no interfaces at all. Ada 95 had everything needed, i.e. >> abstract types. Introducing interfaces in Ada 2005 was a huge mistake. > > Why do you say that? Because there should be a honest MI and no interfaces. > I see them as just being a contract for functions/ > procedures that some object must provide, and in that sense there is > no reason why an actual object-class cannot agree to one or more of > these 'contracts'. One nice thing Delphi did was to allow an interface > to be implemented by a field of the class, they called this "interface > delegation" and looked something like this: > Type TExample = Class(TObject, IDelegated) > private > DelegationField : TSomeDelegatedObject; > public > property Delagator : TSomeDelegatedObject read DelegationField > write DelegationField implements IDelegated; > end; //Example You do not need explicitly named contracts in a language like Ada. The contract of a type is the type itself. Ada has type declarations, public and private. Everything visible related to the type is the contract of. Period. > I suppose you could call it 'subcontracting'. There should be plain interface inheritance instead. If you wanted the type S to implement the interface of the type T *without* inheriting the implementation of T, you should be able to tell just so. Rather than *in advance* trying to declare all possible interfaces. It is awful and leads to an explosion of meaningless declarations like: type T_Interface is interface ... ; -- Just in case we would need it! procedure Foo (X : T_Interface) is abstract; type T is new T_Interface with ...; -- No we starting to work overriding procedure Foo (X : T); That is a mess and a maintenance disaster. >>> If the drive is a dictionary, the entries are the particular files/ >>> directories/objects thereon, but it is pretty useless to give someone >>> a dictionary in a language they can't read. >> >> No, it only means that the object called dictionary is supported and other >> objects called articles are not. The same error was made by the relational >> data bases, they understand the structure of relations (relational >> algebra), but do not do the elements of the tuples. > > I think we have a failure-to-communicate here. I agree that relational > algebra [blindly] works on tuples w/o knowing about the contents... > that is in a sort of abstract fashion. > > If we use metaphor/allegory for the data-system [hard-drive, FS, data] > would you agree that it could be likened to the following? > The hard-drive is like unto a library containing books. > The books of that library are like unto the data/files. > The FS is like unto the indexing system (alphabetically by title, > alphabetically by author, dewy-decimal, etc) coupled with the > methodology for storing the 'books' (are they in boxes, on shelves, in > a pile, etc). > > Can we both agree on this? Sure. Translated to OO: FS is a specialized persistent container library. >>>> Without MI, MD, tagged tasks, there is no chance to get >>>> it right. >> >> >>> If MD is multiple dispatch then we're talking about something that >>> simply explodes combinatorically-speaking: Say we have a multi- >>> dispatch procedure with two dispatching parameters [Letter and >>> Number], ok? Now, if we have two versions of each of those in the >>> classes we get something like: >>> (A,1) >>> (A,2) >>> (B,1) >>> (B,2) >> >> Yes. Let you have printer devices and shapes. This is a classical example >> of MD. Yes, it explodes. That is the law of nature. There is nothing to do >> about it, with MD support or without it, you have these combinations, you >> have to handle them. MD does not solve this, it merely provides an >> infrastructure helping you to solve this. No more, no less. > > Ah, I think I was confusing the problem with that infrastructure > then... > > But that does remind me, I was thinking it would be good to have > PostScript as the display for the OS, unifying the visual display that > way it would eliminate the need for printer drivers (assuming they're > postscript printers) as well as providing a true WYSIWYG for print- > preview (MS's print preview can be a bit... inaccurate), right? Right, but in an OO system you would barely need PostScript. I doubt anybody would like to program in PostScript, so what is left? Poor as a data carrier, unusable for humans. Doesn't it remind something? XML? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Maciej Sobczak on 14 Jan 2010 04:40
On 13 Sty, 10:17, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > > 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. What remote object? I just plugged in my USB stick or spun the DVD in the drive. If you want to see a "remote object" in this operation, you will have to somehow instruct the system that the "remote object" is the one which is on USB. In which case there is no point in having it (unnecessary step) as you might just as well instruct the system that your *local* object should be constructed from what is on the drive, by perhaps providing the file name. Which is exactly what we have today. The high-level OO abstraction still has to hit the bare metal at some point, which only shows that it does not solve any problem, only moves it elsewhere. > > Did I mention that you might want to move you whole hard drive to > > another machine as well? :-) > > Did you try? Sure, my USB stick works fine. > What happens with a NTFS drive in a Linux system? I have no idea since I do not have any NTFS drives around. :-) But I do not see how the OO approach would solve that problem. Plug the OO-aware drive from the OO-aware system from Microsoft into your OO-aware system of choice and you will be in the same mess. Again, no problem solved. (because the problem of compatibility is in standardization, not in paradigm) > > 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. Agreed. OO cannot be done right without these sorted out first. > But the major problem is lack of any interest, since the market > of operating system was burnt down to the ground. Or maybe the problem is that people try to perceive any given paradigm as a silver bullet for solving all problems. I do not think that OO is one (and I though the industry came to this conclusion some 15 years ago already). Personally, I'm not even sure if I would like to use the OS that was made pure-OO from the ground up in all possible aspects. Some paradigm flexibility is needed to find optimal solutions in different situations and that cannot be achieved if a single idea is driving everything. -- Maciej Sobczak * www.msobczak.com * www.inspirel.com Database Access Library for Ada: www.inspirel.com/soci-ada |