* Ada OS based on Minix3 @ 2008-11-07 14:10 Cedric.Lannock 2008-11-07 16:20 ` xavier grave ` (4 more replies) 0 siblings, 5 replies; 40+ messages in thread From: Cedric.Lannock @ 2008-11-07 14:10 UTC (permalink / raw) Hi all, I came across Ada at the beginning of the year and read quite a few books about Ada. A few month later I joined a Linux workgroup within a local computer association. This way I learned about Ada and had a look into Tanenbaum's book on operating systems (http://www.amazon.com/ Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3 (http://www.minix3.org/). I thought about an operating system written fully in Ada. When surfing the net I came across the various discussions about that subject. What taking the Minix 3 system as basis for porting it to Ada? The Minix 3 is a modern micro kernel os and has about 4.000 Lines of code. It is full Posix compatible. Some guys have added real time functionality to it (see ACM.org for further reading). Thus it would a good place to start. As it has to few lines of code it should be possible to build a kernel in overseeable time. Another thought to get this project taking some speed would be not to rewrite all the available C code but to develop a translator c2ada. It would us getting startet and the resulting code could be enhanced and improved. Do you think this would make this project doable? Regards Cedric Lannock ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock @ 2008-11-07 16:20 ` xavier grave 2008-11-08 3:46 ` anon ` (3 subsequent siblings) 4 siblings, 0 replies; 40+ messages in thread From: xavier grave @ 2008-11-07 16:20 UTC (permalink / raw) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cedric.Lannock a �crit : > Hi all, > > I came across Ada at the beginning of the year and read quite a few > books about Ada. A few month later I joined a Linux workgroup within a > local computer association. This way I learned about Ada and had a > look into Tanenbaum's book on operating systems (http://www.amazon.com/ > Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ > ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3 > (http://www.minix3.org/). > > I thought about an operating system written fully in Ada. When surfing > the net I came across the various discussions about that subject. > > What taking the Minix 3 system as basis for porting it to Ada? The > Minix 3 is a modern micro kernel os and has about 4.000 Lines of code. > It is full Posix compatible. Some guys have added real time > functionality to it (see ACM.org for further reading). Thus it would a > good place to start. As it has to few lines of code it should be > possible to build a kernel in overseeable time. > > Another thought to get this project taking some speed would be not to > rewrite all the available C code but to develop a translator c2ada. It > would us getting startet and the resulting code could be enhanced and > improved. > > Do you think this would make this project doable? > > Regards > > Cedric Lannock Hi Cedric, I have started to develop some kind of OS fully in Ada : Lovelace. I have thought recently to restart all of it on a minix3 basis, but the lack of Virtual Memory handling stopped me (as far as I understood minix3) and also that minix has is proper compiler which isn't gcc. And something I definitively don't want to do is to write an Ada compiler to produce minix binary format. Perhaps adapt GNAT to minix is a reseanable project but it doesn't seem so to me. If you want we can try to join our forces for building a fully Ada OS. Cordially, xavier PS: My work is mainly a translation from C to Ada of the SOS work[1]. This isn't a strict translation and for example exception support is enabled from the very beginning of the kernel boot (ease a lot the kernel debugging). Here is a monotone repository with the last lovelace code : [2]. For more information about accessing this monotone server : [3]. There is already some Ada OS available like MarteOS (not full Ada code as far as I understand, list of Ada OS not exhaustive). [1]http://sos.enix.org/en/MainPage [2]http://www.ada-france.org:8081/branch/changes/org.os-lovelace [3]http://www.ada-france.org/article131.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkUas0ACgkQVIZi0A5BZF58HQCffCisIi0ogUk4QMrFqtyvUrLf npQAn24u86fEg05jhEl/FDDu1zV2SkAA =i1AY -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock 2008-11-07 16:20 ` xavier grave @ 2008-11-08 3:46 ` anon 2008-11-10 8:12 ` Ivan Levashew ` (2 subsequent siblings) 4 siblings, 0 replies; 40+ messages in thread From: anon @ 2008-11-08 3:46 UTC (permalink / raw) There are a number of Ada OSs like that are Posix based: (All based on GNAT Ada) "Lovelace" by xavier grave (active project) MaRTE project (still activity) RTEMS project For a kernel completely written in Ada may be an idea, but in today's world it might be hard to do. A lot of kernel authors use GNAT, but GNAT was not designed to create stand-alone bootable code. And with GCC not fully supporting 16-bit code generation, GNAT can not fully generate a Legacy bootable code. But there may be hope, do to newer motherboards using newer BIOS based on INTEL EFI specs, like the AMIBIOS with Aptio EFI Firmware. These new BIOSs asap switch the processing mode to Protected-Mode then boot the OS as an 32 or 64 bit protected-mode application. Plus, protected-mode hardware device drivers can be loaded in a Flash device driver BIOS area. For older motherboard, one might try CoreBoot aka LinuxBIOS. But for now most people just use the GRUB boot loader which is written in C and that kind of defect the concept of 100% Ada OS. So, it might be take some time to see a true 100% kernel. Note: ASUS, INTEL and others are schedule to use the new AMI Protected-Mode BIOS in the second/third quarters of 2008. Which means that someone should be able to write a multi-functional boot loader completely in Ada and then the kernel in 100% Ada code for some. But changing out all of the Legacy based BIOS or upgrade motherboards will still take a long time. Now, I have written a couple of Ada (MBR) (Intel based) boot loaders using GNAT using gcc 3.2 that can boot an Ada kernel from either a floppy or bootable CD. It can be done using GNAT 2007 but the process is more involved. Also at the movement I prefer nonposix design. Plus there is some talk that the EFI Firmware spec may replace some of the POSIX spec. Plus, to me why, reinvent the wheel aka another Posix OS. Those who start to write an Ada OS kernel should prove that Ada is better by showing there is a better interface than just another Posix. Maybe calling it Aside (Ada Operating System Interface) which could include a posix addon module. This posix module could be use as a less secure interfere to existing non Ada software. But for the true ability of the Ada OS then an application would be needed to be written in Ada using Aosix. And as for "c2ada" there is a couple of projects that do work, but they are at the movement limited to either Ada 83 or Ada 95 specs. But with the Posix add on module to an Ada OS that would allow C code to be use, once the kernel and base apps are written in Ada. As for using Minix 3 as a base for the an Ada OS. If you borrow a routine or two that's OK, but to base a complete design on anyone else's work is just a type of plagiarism, that I am not into. And you only prove that the original author could of used Ada, but not that Ada is better for writing an OS. Or that an Ada OS can stand on it on merits. The best why is to create a totally new design that take the best concepts from a majority of OS and try to limit the worst concepts that those OS have. In <ed7d1ea9-bf0b-4e4a-b317-b57102853d65@p35g2000prm.googlegroups.com>, "Cedric.Lannock" <Cedric.Lannock@gmx.net> writes: >Hi all, > >I came across Ada at the beginning of the year and read quite a few >books about Ada. A few month later I joined a Linux workgroup within a >local computer association. This way I learned about Ada and had a >look into Tanenbaum's book on operating systems (http://www.amazon.com/ >Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ >ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3 >(http://www.minix3.org/). > >I thought about an operating system written fully in Ada. When surfing >the net I came across the various discussions about that subject. > >What taking the Minix 3 system as basis for porting it to Ada? The >Minix 3 is a modern micro kernel os and has about 4.000 Lines of code. >It is full Posix compatible. Some guys have added real time >functionality to it (see ACM.org for further reading). Thus it would a >good place to start. As it has to few lines of code it should be >possible to build a kernel in overseeable time. > >Another thought to get this project taking some speed would be not to >rewrite all the available C code but to develop a translator c2ada. It >would us getting startet and the resulting code could be enhanced and >improved. > >Do you think this would make this project doable? > >Regards > >Cedric Lannock ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock 2008-11-07 16:20 ` xavier grave 2008-11-08 3:46 ` anon @ 2008-11-10 8:12 ` Ivan Levashew 2008-11-10 8:58 ` Dmitry A. Kazakov 2008-11-10 10:18 ` Ada OS based on Minix3 Georg Bauhaus 2008-11-11 1:00 ` Freejack 2008-11-11 8:32 ` Martin Krischik 4 siblings, 2 replies; 40+ messages in thread From: Ivan Levashew @ 2008-11-10 8:12 UTC (permalink / raw) Cedric Lannock wrote: > As it has to few lines of code it should be > possible to build a kernel in overseeable time. Kernel isn't enough. Drivers, applications. And, the most essential thing, users' and developers' awareness, what's wrong with other OSes; what's wrong with GNU, Microsoft and Apple. I'm wondering what you're trying to achieve with Ada OS? Is it just a casting tech skills? Two general problems of starting an enterprise Ada project are as follows: Lack of libraries Lack of developers While you can do little about the second, you can at least do binding generators. There are 2 unfinished ones: GNATCOM and GNAT-SWIG. GNATCOM is part of GNAVI project. GNAVI was quite popular several years ago. GNATCOM fails to compile on latest GNAT (Ada 2005). I have succeded in making it running and created a demo Delphi+Ada webserver using it. One need to delete "-gnatg" option out of GNATCOM Makefiles and rename GNATCOM.Interface package to another name, e. g. COM_Interface. It will at least be working, but still not convenient to use (due to thinness of data types, e. g. one has to write Issue.Attach (DB_Access.Get_Issue); Rubrics.Attach (Issue.Get_Rubrics); instead of DB_Access.Issue.Rubrics). GNATCOM doesn't claim to be thick binding generator after all. Another unfinished stuff is GNAT-SWIG. It was started in 2006, when Ada 2005 implementation wasn't stable and complete. An essential thing like GNAT-SWIG should feel like Ada 2005, so it might need to be changed as well. Or, if you want to start from scratch, you have an option to make binding generator for XPCOM and UNO (OpenOffice.org). First will give a good crossplatform UI. Starting from v1.9, Gecko finally got Mac OS X right, and it's currently AFAIK the only UI engine that feels native on every OS. UNO bindings will enable Ada applications to portably manage Office documents. The work to be done is as hardcore as writing OS, yet indeed much more people would benefit from it. I don't think that something 100% Ada is a good idea because nowadays lorry number of such projects is very small. > > Another thought to get this project taking some speed would be not to > rewrite all the available C code but to develop a translator c2ada. It > would us getting startet and the resulting code could be enhanced and > improved. > I have a better idea: first, manually convert C code to Cyclone code (that's what Cyclone is really good for). Then it could be more easily translated into Ada code. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:12 ` Ivan Levashew @ 2008-11-10 8:58 ` Dmitry A. Kazakov 2008-11-10 9:26 ` Ivan Levashew ` (3 more replies) 2008-11-10 10:18 ` Ada OS based on Minix3 Georg Bauhaus 1 sibling, 4 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-10 8:58 UTC (permalink / raw) On Mon, 10 Nov 2008 00:12:10 -0800 (PST), Ivan Levashew wrote: > Two general problems of starting an enterprise Ada project are as > follows: > Lack of libraries > Lack of developers First of all, lack of ideas. It makes no sense to make yet another linux. In my opinion an Ada OS, if there should be one, must be fully OO and have native Ada interface. In order to achieve this, much has to be done at the language level first. An OO OS is unthinkable without MI, MD and safe (non-cooperative) tasks and protected objects. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:58 ` Dmitry A. Kazakov @ 2008-11-10 9:26 ` Ivan Levashew 2008-11-10 10:11 ` Georg Bauhaus ` (2 subsequent siblings) 3 siblings, 0 replies; 40+ messages in thread From: Ivan Levashew @ 2008-11-10 9:26 UTC (permalink / raw) > First of all, lack of ideas. I don't think an idea will help much. IMHO currently dirty work matters. IDE integration plugins, protocol implementations. Scripting languages extension toolkits. Tutorials. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:58 ` Dmitry A. Kazakov 2008-11-10 9:26 ` Ivan Levashew @ 2008-11-10 10:11 ` Georg Bauhaus 2008-11-10 10:24 ` Jacob Sparre Andersen 2008-11-10 10:50 ` Ivan Levashew 3 siblings, 0 replies; 40+ messages in thread From: Georg Bauhaus @ 2008-11-10 10:11 UTC (permalink / raw) Dmitry A. Kazakov schrieb: > It makes no sense to make yet another linux. This is a reason for suggesting Minix which is---and was---not another Linux. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:58 ` Dmitry A. Kazakov 2008-11-10 9:26 ` Ivan Levashew 2008-11-10 10:11 ` Georg Bauhaus @ 2008-11-10 10:24 ` Jacob Sparre Andersen 2008-11-10 10:51 ` Dmitry A. Kazakov 2008-11-10 10:50 ` Ivan Levashew 3 siblings, 1 reply; 40+ messages in thread From: Jacob Sparre Andersen @ 2008-11-10 10:24 UTC (permalink / raw) Dmitry A. Kazakov wrote: > It makes no sense to make yet another linux. In a way, I agree. But at the same time, I like to have the freedom to choose among several different, free/Open Source, POSIX compliant operating systems. > In my opinion an Ada OS, if there should be one, must be fully OO > and have native Ada interface. Why should it necessarily be object oriented? I think the important part in writing an operating system is to figure out how you can do it "better". If we want to write an operating system in Ada, we should consider how we can make a "better" operating system using that. It seems that "better" in this case is reliability, maintenance and efficiency. I am not sure if this is done best using "full OO" or not. Personally I appreciate standards compliance, so I would probably include a POSIX API on the feature list. > In order to achieve this, much has to be done at the language level > first. In the sense that the language should be changed? (Would it still be Ada then? :-) Greetings, Jacob -- "Genes don't matter. It's all physics." ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 10:24 ` Jacob Sparre Andersen @ 2008-11-10 10:51 ` Dmitry A. Kazakov 2008-11-10 11:07 ` Ludovic Brenta 0 siblings, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-10 10:51 UTC (permalink / raw) On 10 Nov 2008 11:24:58 +0100, Jacob Sparre Andersen wrote: > Dmitry A. Kazakov wrote: > >> It makes no sense to make yet another linux. > > In a way, I agree. But at the same time, I like to have the freedom > to choose among several different, free/Open Source, POSIX compliant > operating systems. Freedom of choice assumes diversity. There is not much diversity in what is called "modern" OSes. In recent time worked mainly with Windows, Linux, VxWorks (before that I did with Sys V, VMS, Solaris). I just don't consider them conceptually different. IMO it makes no sense to have another one like these. >> In my opinion an Ada OS, if there should be one, must be fully OO >> and have native Ada interface. > > Why should it necessarily be object oriented? Because otherwise OS is damned to have a very low-level interface. The sad consequence of this are poorly integrated OS-like additional storeys with a huge overhead due to interface impedance. DBMS is one notorious example. Others are numerous middlewares like CORBA etc. This architecture has no future, IMO. > I think the important part in writing an operating system is to figure > out how you can do it "better". If we want to write an operating > system in Ada, we should consider how we can make a "better" operating > system using that. It seems that "better" in this case is > reliability, maintenance and efficiency. Yes, but note, you were talking about *non-functional* requirements, here. It is placing a cart before the horse. > I am not sure if this is > done best using "full OO" or not. OO is not a tool here, it is a goal, a *functional* requirement. Others are to have it embeddable, heterogeneous, distributed, with persistent objects. > Personally I appreciate standards compliance, so I would probably > include a POSIX API on the feature list. POSIX is on the top of the list ... of thing to scrap ... >> In order to achieve this, much has to be done at the language level >> first. > > In the sense that the language should be changed? (Would it still be > Ada then? :-) Sure. Ada means "designed to support the construction of long-lived, highly reliable software systems" ARM 1/1. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 10:51 ` Dmitry A. Kazakov @ 2008-11-10 11:07 ` Ludovic Brenta 2008-11-10 11:42 ` Ivan Levashew 2008-11-11 22:16 ` Robert A Duff 0 siblings, 2 replies; 40+ messages in thread From: Ludovic Brenta @ 2008-11-10 11:07 UTC (permalink / raw) Ivan and Dmitry, you are discussing the viability of an operating system written in Ada but, I think, you are missing the OP's point. Cedric does not seem to care whether there is a market opportunity or what breakthrough technology he might want to introduce; he wants to learn kernel design (from Tanenbaum) and Ada (from various books and us). Yes, he would be reinventing the wheel. But in this process he could become a master wheel-builder just like one Linus Torvalds before him. Sometimes, "reinventing" is precisely the goal. If nobody ever "reinvented", then nobody would learn to "invent" new things. So, Cedric, I encourage you to pursue this idea of yours. Lovelace is still small enough to be comprehensible by a single person, so, if you would like to work with other people and receive feedback, joining forces with Xavier Grave on this project is a good idea. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 11:07 ` Ludovic Brenta @ 2008-11-10 11:42 ` Ivan Levashew 2008-11-10 12:04 ` Ludovic Brenta 2008-11-11 22:16 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Ivan Levashew @ 2008-11-10 11:42 UTC (permalink / raw) Ludovic Brenta wrote: > Ivan and Dmitry, you are discussing the viability of an operating > system written in Ada but, I think, you are missing the OP's point. > Cedric does not seem to care whether there is a market opportunity or > what breakthrough technology he might want to introduce; he wants to > learn kernel design (from Tanenbaum) and Ada (from various books and > us). Yes, he would be reinventing the wheel. I'm not against wheels. I'm against projects with small lorry number. There are lots of collecting dust. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 11:42 ` Ivan Levashew @ 2008-11-10 12:04 ` Ludovic Brenta 0 siblings, 0 replies; 40+ messages in thread From: Ludovic Brenta @ 2008-11-10 12:04 UTC (permalink / raw) Ivan Levashew wrote: > I'm not against wheels. I'm against projects with small lorry number. > There are lots of collecting dust. What is a "small lorry number" ? -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 11:07 ` Ludovic Brenta 2008-11-10 11:42 ` Ivan Levashew @ 2008-11-11 22:16 ` Robert A Duff 2008-11-12 6:28 ` Ivan Levashew 1 sibling, 1 reply; 40+ messages in thread From: Robert A Duff @ 2008-11-11 22:16 UTC (permalink / raw) Ludovic Brenta <ludovic@ludovic-brenta.org> writes: > Ivan and Dmitry, you are discussing the viability of an operating > system written in Ada but, I think, you are missing the OP's point. > Cedric does not seem to care whether there is a market opportunity or > what breakthrough technology he might want to introduce; he wants to > learn kernel design (from Tanenbaum) and Ada (from various books and > us). All the more reason to do something "new" and "interesting", rather than cloning the posix "wheel". Nothing wrong with taking inspiration from Minix/Tanenbaum, but for a hobby project, why not try out some new ideas as well? >... Yes, he would be reinventing the wheel. But in this process he > could become a master wheel-builder just like one Linus Torvalds > before him. Sometimes, "reinventing" is precisely the goal. If nobody > ever "reinvented", then nobody would learn to "invent" new things. > > So, Cedric, I encourage you to pursue this idea of yours. Lovelace is > still small enough to be comprehensible by a single person, so, if you > would like to work with other people and receive feedback, joining > forces with Xavier Grave on this project is a good idea. - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 22:16 ` Robert A Duff @ 2008-11-12 6:28 ` Ivan Levashew 0 siblings, 0 replies; 40+ messages in thread From: Ivan Levashew @ 2008-11-12 6:28 UTC (permalink / raw) > > Nothing wrong with taking inspiration from Minix/Tanenbaum, > but for a hobby project, why not try out some new ideas as well? > E.g. choose Plan9 instead of Minix3. Plan9 ideas can still be considered novel. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:58 ` Dmitry A. Kazakov ` (2 preceding siblings ...) 2008-11-10 10:24 ` Jacob Sparre Andersen @ 2008-11-10 10:50 ` Ivan Levashew 2008-11-10 11:01 ` Dmitry A. Kazakov 3 siblings, 1 reply; 40+ messages in thread From: Ivan Levashew @ 2008-11-10 10:50 UTC (permalink / raw) > In my opinion an Ada OS, if there should be one, must be fully OO and have > native Ada interface. Which is unthinkable without Ada ABI. I'm missing Dylan's "sealed/ unsealed". > An OO OS is unthinkable without MI, MD and safe > (non-cooperative) tasks and protected objects. What PL family do you mean: Sather/Eiffel, C++, Dylan/CLOS? BTW, in '88 or so there existed an OO-extension for Ada. It was called InnovAda. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 10:50 ` Ivan Levashew @ 2008-11-10 11:01 ` Dmitry A. Kazakov 2008-11-10 15:31 ` Robert A Duff 0 siblings, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-10 11:01 UTC (permalink / raw) On Mon, 10 Nov 2008 02:50:22 -0800 (PST), Ivan Levashew wrote: >> In my opinion an Ada OS, if there should be one, must be fully OO and have >> native Ada interface. > > Which is unthinkable without Ada ABI. I'm missing Dylan's "sealed/ > unsealed". Well, maybe. It is required if agents (mobile object) have to be supported on the OS level. >> An OO OS is unthinkable without MI, MD and safe >> (non-cooperative) tasks and protected objects. > > What PL family do you mean: > Sather/Eiffel, C++, Dylan/CLOS? Ada > BTW, in '88 or so there existed an OO-extension for Ada. It was called > InnovAda. I never heard about it. I am satisfied with Ada 95 OO model. It was consistent but incomplete. Now it must be made finished. Major things to add are: 1. Classes for all types 2. MI 3. MD 4. Supertypes 5. Procedural types 6. Proper construction/destruction For OS: 7. Non-cooperative multitasking -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 11:01 ` Dmitry A. Kazakov @ 2008-11-10 15:31 ` Robert A Duff 2008-11-10 15:56 ` Dmitry A. Kazakov 0 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2008-11-10 15:31 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > 6. Proper construction/destruction What do you see as the limitations/problems with Ada in this area? - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 15:31 ` Robert A Duff @ 2008-11-10 15:56 ` Dmitry A. Kazakov 2008-11-11 22:09 ` Robert A Duff 0 siblings, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-10 15:56 UTC (permalink / raw) On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> 6. Proper construction/destruction > > What do you see as the limitations/problems with Ada in this area? 1. User-defined initialization/finalization shall be definable for any type. I do mean any. 2. Composition rules of initialization/finalization for derived types must ensure execution of the user-defined initialization/finalization code for the base type. 3. User-defined initialization/finalization shall be definable for class-wide types. AKA dispatch from constructor/destructor. Actually, a part of the pos. 1. 4. Task-as-a-component problem to be solved. 5. Getting a pool-specific pointer to the object upon initialization/finalization, when the object is allocated in such a pool. (Unchecked_Conversion is really nasty there) 6. LHS/RHS issue. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 15:56 ` Dmitry A. Kazakov @ 2008-11-11 22:09 ` Robert A Duff 2008-11-12 9:47 ` Dmitry A. Kazakov 0 siblings, 1 reply; 40+ messages in thread From: Robert A Duff @ 2008-11-11 22:09 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> 6. Proper construction/destruction >> >> What do you see as the limitations/problems with Ada in this area? > > 1. User-defined initialization/finalization shall be definable for any > type. I do mean any. Finalization: Agreed, but the compiler really needs to take care to avoid distributed overhead. Initialization: Use function calls. They work for all types. I think we've discussed this idea before, but I don't remember any fundamental problems. The Initialize procedure of controlled types seems unnecessary to me (although something needs to be done regarding abort deferral). > 2. Composition rules of initialization/finalization for derived types must > ensure execution of the user-defined initialization/finalization code for > the base type. Agreed (except I think you mean "parent type", not "base type"). This is a more general issue -- it would be useful to say "must call parent op" for various things, including Finalize. > 3. User-defined initialization/finalization shall be definable for > class-wide types. AKA dispatch from constructor/destructor. Actually, a > part of the pos. 1. OK. There are some interesting issues here -- the constructor (a function, in my mind) might want to plug a pointer-to-classwide into some global data structure, but I want to make sure the specific-typed thing is fully initialized and ready to be dispatched to, before that happens. > 4. Task-as-a-component problem to be solved. Which problem is that? > 5. Getting a pool-specific pointer to the object upon > initialization/finalization, when the object is allocated in such a pool. > (Unchecked_Conversion is really nasty there) I think you mean Unchecked_Access -- Unchecked_Conversion is not necessary. I don't see how this can make sense. In Initialize or Finalize, you don't know whether the object is in a pool, nor which pool. So how can you get a pool-specific pointer? Also, given point 1 ("any type") the thing being init/finalized could be a bitfield component of a packed record. Pointers to bitfields could cause distributed overhead, if you're not careful. > 6. LHS/RHS issue. What issue is that? How about: 7. It would be nice if Finalize would be passed a parameter indicating the reason for finalization (normal exit, some exception occurrence, abort). Perhaps also an ability to declare that finalization only applies to certain "reasons". 8. Interactions with user-defined storage pools. 9. Interactions with garbage collection. 10. Reify the finalization operation (that is, the operation on some type that calls Finalize on all the parts of it, including the whole). - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 22:09 ` Robert A Duff @ 2008-11-12 9:47 ` Dmitry A. Kazakov 2008-11-13 0:58 ` Randy Brukardt 2008-11-14 23:11 ` Robert A Duff 0 siblings, 2 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-12 9:47 UTC (permalink / raw) On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Mon, 10 Nov 2008 10:31:27 -0500, Robert A Duff wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> 6. Proper construction/destruction >>> >>> What do you see as the limitations/problems with Ada in this area? >> >> 1. User-defined initialization/finalization shall be definable for any >> type. I do mean any. > > Finalization: Agreed, but the compiler really needs to take care to > avoid distributed overhead. I don't see why it should be a distributed overhead. For example, access types are already initialized by null. The overhead, if any, is here, but it does not hurt. > Initialization: Use function calls. They work for all types. > I think we've discussed this idea before, but I don't remember > any fundamental problems. The fundamental problem is that a constructor cannot be decomposed into functions. In the function body you have to construct the object before you return it. Who does it and what? Under initialization I do not mean replacing a "default" value with something else. I mean creation a new object (at some memory location) initialized by a value. It had no other value before. Doing this by a function is semantically wrong. > The Initialize procedure of controlled > types seems unnecessary to me (although something needs to be done > regarding abort deferral). Right, because Initialize receives an already constructed object. It is too late to do many type-specific initializations, but too early to make the class-wide ones. >> 2. Composition rules of initialization/finalization for derived types must >> ensure execution of the user-defined initialization/finalization code for >> the base type. > > Agreed (except I think you mean "parent type", not "base type"). Well, I am unsure if there must be such distinction in the first place. But, OK, to begin with, let it be parent type. > This is a more general issue -- it would be useful to say > "must call parent op" for various things, including Finalize. Yes, it would be great to have "extensible" primitive operations. >> 3. User-defined initialization/finalization shall be definable for >> class-wide types. AKA dispatch from constructor/destructor. Actually, a >> part of the pos. 1. > > OK. There are some interesting issues here -- the constructor (a > function, in my mind) might want to plug a pointer-to-classwide into > some global data structure, but I want to make sure the specific-typed > thing is fully initialized and ready to be dispatched to, before that > happens. Right. >> 4. Task-as-a-component problem to be solved. > > Which problem is that? I mean the pattern: type Active is new Ada.Finalization.Limited_Controlled ...; private task Agent (Object : not null access Active'Class) ... type Active is new Ada.Finalization.Limited_Controlled with record Agent : Task (Active'Access); end record; It is broken, not even worth to try. Even in rare cases when the component task does not refer to its container type, the only way to make it working is to have a pointer to the task instead. In fact, any mix-in with an access to class-wide is extremely dangerous and error prone, *because* it is very difficult to initialize and finalize such things properly. But this is another story (about why we should have MI). >> 5. Getting a pool-specific pointer to the object upon >> initialization/finalization, when the object is allocated in such a pool. >> (Unchecked_Conversion is really nasty there) > > I think you mean Unchecked_Access -- Unchecked_Conversion is not > necessary. > > I don't see how this can make sense. In Initialize or Finalize, you > don't know whether the object is in a pool, nor which pool. So how can > you get a pool-specific pointer? That is exactly the problem. Consider objects allocated on a user-defined pool. The object are linked into some list. When a new object is created the "constructor" places it into the list. When the object is destroyed, the "destructor" removes it. For both, you need a self-pointer, but you cannot get it from an "in out" parameter. If access types had constructors/destructors, the programmer could place that stuff there, rather that trying to do it in the object. It does not belong there. > Also, given point 1 ("any type") the thing being init/finalized could be > a bitfield component of a packed record. Pointers to bitfields could > cause distributed overhead, if you're not careful. This is an issue how a constructor is chosen by the compiler. >> 6. LHS/RHS issue. > > What issue is that? I meant access to the left part of assignment. Provided that the assignment is to be generated out of the constructor and destructor. > How about: > > 7. It would be nice if Finalize would be passed a parameter indicating > the reason for finalization (normal exit, some exception occurrence, > abort). Perhaps also an ability to declare that finalization only > applies to certain "reasons". Yes, I always wished to have this for DB transaction objects. When the object is killed by an exception propagation it rolls the updates back. Otherwise it commits. > 8. Interactions with user-defined storage pools. > > 9. Interactions with garbage collection. I hope this can be solved on the basis of the constructor/destructor of the corresponding access type. Pool-specific named access types is one of the coolest things in Ada, IMO. > 10. Reify the finalization operation (that is, the operation on some > type that calls Finalize on all the parts of it, including the > whole). I.e. a destructor. But it is semantically broken to have such. It would destroy an object leaving a dangling typed name of. I think that the trick can be achieved with an access type to some fake storage pool. The Unchecked_Deallocation is called on the pointer. That does the finalization. Then the pool's Deallocate is called, which does nothing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-12 9:47 ` Dmitry A. Kazakov @ 2008-11-13 0:58 ` Randy Brukardt 2008-11-13 17:28 ` Dmitry A. Kazakov 2008-11-14 23:11 ` Robert A Duff 1 sibling, 1 reply; 40+ messages in thread From: Randy Brukardt @ 2008-11-13 0:58 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net... ... >>> 5. Getting a pool-specific pointer to the object upon >>> initialization/finalization, when the object is allocated in such a >>> pool. >>> (Unchecked_Conversion is really nasty there) >> >> I think you mean Unchecked_Access -- Unchecked_Conversion is not >> necessary. >> >> I don't see how this can make sense. In Initialize or Finalize, you >> don't know whether the object is in a pool, nor which pool. So how can >> you get a pool-specific pointer? > > That is exactly the problem. Consider objects allocated on a user-defined > pool. The object are linked into some list. When a new object is created > the "constructor" places it into the list. When the object is destroyed, > the "destructor" removes it. For both, you need a self-pointer, but you > cannot get it from an "in out" parameter. Sorry, but this is completely wrong. This is *exactly* how Claw works, and it works fine with Ada 95. It is perfectly OK to get a pointer from a parameter of a tagged object. You do have to use 'Unchecked_Access, but that is no problem if you are using Finalize to clean up. ... >> 10. Reify the finalization operation (that is, the operation on some >> type that calls Finalize on all the parts of it, including the >> whole). > > I.e. a destructor. But it is semantically broken to have such. It would > destroy an object leaving a dangling typed name of. > > I think that the trick can be achieved with an access type to some fake > storage pool. The Unchecked_Deallocation is called on the pointer. That > does the finalization. Then the pool's Deallocate is called, which does > nothing. Yup. And you can do that now. So what's the big deal. At worst, it's not as convinient as it could be. Most of the rest of the stuff that you and Bob have talked about is too incompatible to consider for Ada. A new Ada-like language could do these things, but there isn't much likelyhood of anyone using that. Randy. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-13 0:58 ` Randy Brukardt @ 2008-11-13 17:28 ` Dmitry A. Kazakov 2008-11-13 23:25 ` Randy Brukardt 0 siblings, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-13 17:28 UTC (permalink / raw) On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net... > ... >>>> 5. Getting a pool-specific pointer to the object upon >>>> initialization/finalization, when the object is allocated in such a >>>> pool. >>>> (Unchecked_Conversion is really nasty there) >>> >>> I think you mean Unchecked_Access -- Unchecked_Conversion is not >>> necessary. >>> >>> I don't see how this can make sense. In Initialize or Finalize, you >>> don't know whether the object is in a pool, nor which pool. So how can >>> you get a pool-specific pointer? >> >> That is exactly the problem. Consider objects allocated on a user-defined >> pool. The object are linked into some list. When a new object is created >> the "constructor" places it into the list. When the object is destroyed, >> the "destructor" removes it. For both, you need a self-pointer, but you >> cannot get it from an "in out" parameter. > > Sorry, but this is completely wrong. This is *exactly* how Claw works, and > it works fine with Ada 95. It is perfectly OK to get a pointer from a > parameter of a tagged object. You do have to use 'Unchecked_Access, but that > is no problem if you are using Finalize to clean up. No, that does not work with pool-specific types: with Ada.Finalization; package Test_Unchecked is type T is new Ada.Finalization.Limited_Controlled with private; overriding procedure Initialize (X : in out T); overriding procedure Finalize (X : in out T); private type T_Ptr is access T'Class; type T is new Ada.Finalization.Limited_Controlled with null record; Global : T_Ptr; end Test_Unchecked; procedure Initialize (X : in out T) is begin Add_To_List (Global, X'Unchecked_Access); -- Illegal, general access is required, but T_Ptr is expected end Initialize; And it is error-prone. There should be nothing "unchecked" there. If access type had its own initialization/finalization hooks at appropriate places, we could move that stuff where it actually belongs to. After all, you could have: type T_Pool_1_Ptr is access T'Class; for T_Pool_1_Ptr'Storage_Pool use Pool_1; Global_1 : T_Pool_1_Ptr; type T_Pool_2_Ptr is access T'Class; for T_Pool_2_Ptr'Storage_Pool use Pool_2; Global_2 : T_Pool_2_Ptr; Objects allocated in Pool_1 are placed into Global_1 list. Objects allocated in Pool_2 are in Global_2. Object initialization is just a wrong place to manipulate these lists. > Most of the rest of the stuff that you and Bob have talked about is too > incompatible to consider for Ada. I strongly disagree. I see no incompatibilities. I think that proper construction can be added without changing existing language behaviour. Even Ada.Finalization can be left as-is. Return statements and functions returning limited objects were IMO much more obtrusive. "not null" stuff was plainly incompatible with Ada 95. Nevertheless they were accepted. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-13 17:28 ` Dmitry A. Kazakov @ 2008-11-13 23:25 ` Randy Brukardt 2008-11-14 9:30 ` Dmitry A. Kazakov 0 siblings, 1 reply; 40+ messages in thread From: Randy Brukardt @ 2008-11-13 23:25 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message news:192kzxoa5qgu3.170vbwrazvhvp.dlg@40tude.net... > On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >> news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net... >> ... >>>>> 5. Getting a pool-specific pointer to the object upon >>>>> initialization/finalization, when the object is allocated in such a >>>>> pool. >>>>> (Unchecked_Conversion is really nasty there) >>>> >>>> I think you mean Unchecked_Access -- Unchecked_Conversion is not >>>> necessary. >>>> >>>> I don't see how this can make sense. In Initialize or Finalize, you >>>> don't know whether the object is in a pool, nor which pool. So how can >>>> you get a pool-specific pointer? >>> >>> That is exactly the problem. Consider objects allocated on a >>> user-defined >>> pool. The object are linked into some list. When a new object is created >>> the "constructor" places it into the list. When the object is destroyed, >>> the "destructor" removes it. For both, you need a self-pointer, but you >>> cannot get it from an "in out" parameter. >> >> Sorry, but this is completely wrong. This is *exactly* how Claw works, >> and >> it works fine with Ada 95. It is perfectly OK to get a pointer from a >> parameter of a tagged object. You do have to use 'Unchecked_Access, but >> that >> is no problem if you are using Finalize to clean up. > > No, that does not work with pool-specific types: As well it shouldn't. A decent abstraction should never, ever make assumptions about how the objects are created/allocated/managed. Doing so prevents the use of less-errorprone, more modern management schemes such as stack allocated objects and containers. ... > And it is error-prone. There should be nothing "unchecked" there. I don't disagree, but the use of access types should be a last resort. And they are error-prone by definition (the only way to make them not error-prone is to use local access types, but that assuredly finalizes things too soon, rather than too late). Trying to make them not error-prone is like putting wheels on a horse and calling an automobile. > If access type had its own initialization/finalization hooks at > appropriate > places, we could move that stuff where it actually belongs to. Probably true, but completely irrelevant to my point. ... >> Most of the rest of the stuff that you and Bob have talked about is too >> incompatible to consider for Ada. > > I strongly disagree. I see no incompatibilities. I think that proper > construction can be added without changing existing language behaviour. > Even Ada.Finalization can be left as-is. We have proper construction. You just don't like the way it is written. (Neither did I, initially. But it is the way it is done.) The only problem with constructors is constructing into constrained objects. But that's easily solved: DON'T DO THAT!!! Don't export discriminants or bounds from your abstractions; declare them indefinite (with (<>)) and there are no issues. (Outside of the wording problems in the Standard -- it doesn't quite capture the intent -- but we're fixing them.) > Return statements and functions returning limited objects were IMO much > more obtrusive. "not null" stuff was plainly incompatible with Ada 95. > Nevertheless they were accepted. And we've taken a lot of flack for it. Going forward, we're probably going to be making many fewer incompatible changes. And changing the place that allocated objects finalize (needed for your access type finalization proposal) or where tasks finalize (mentioned as one of your bullets) is just too likely to break existing code. I know Claw would break badly if the latter was changed. Moreover, I recall griping about the same problem you are complaining about vis-a-vis tasks when we were working on Claw -- but I looked at the alternatives, and they were all worse (much more likely to access stack objects that no longer exist, and thus requiring overhead-increasing dynamic checks). I don't think some of these problems are solveable within the constraints of the Ada language. (I'd like to be proved wrong, but I'd need to see a fully worked out proposal before I'd believe it.) Randy. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-13 23:25 ` Randy Brukardt @ 2008-11-14 9:30 ` Dmitry A. Kazakov 0 siblings, 0 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-14 9:30 UTC (permalink / raw) On Thu, 13 Nov 2008 17:25:53 -0600, Randy Brukardt wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message > news:192kzxoa5qgu3.170vbwrazvhvp.dlg@40tude.net... >> On Wed, 12 Nov 2008 18:58:33 -0600, Randy Brukardt wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message >>> news:14ay3vz2ngj9s.1bmilwgckl3lc$.dlg@40tude.net... >>> ... >>>>>> 5. Getting a pool-specific pointer to the object upon >>>>>> initialization/finalization, when the object is allocated in such a >>>>>> pool. >>>>>> (Unchecked_Conversion is really nasty there) >>>>> >>>>> I think you mean Unchecked_Access -- Unchecked_Conversion is not >>>>> necessary. >>>>> >>>>> I don't see how this can make sense. In Initialize or Finalize, you >>>>> don't know whether the object is in a pool, nor which pool. So how can >>>>> you get a pool-specific pointer? >>>> >>>> That is exactly the problem. Consider objects allocated on a >>>> user-defined >>>> pool. The object are linked into some list. When a new object is created >>>> the "constructor" places it into the list. When the object is destroyed, >>>> the "destructor" removes it. For both, you need a self-pointer, but you >>>> cannot get it from an "in out" parameter. >>> >>> Sorry, but this is completely wrong. This is *exactly* how Claw works, >>> and >>> it works fine with Ada 95. It is perfectly OK to get a pointer from a >>> parameter of a tagged object. You do have to use 'Unchecked_Access, but >>> that >>> is no problem if you are using Finalize to clean up. >> >> No, that does not work with pool-specific types: > > As well it shouldn't. A decent abstraction should never, ever make > assumptions about how the objects are created/allocated/managed. Right, and it does not. The object here is of a pool-specific access type (access T'Class). We do not care how these objects are allocated. But we do care how the target objects (T'Class) are allocated because that is the core functionality of the access type. >> And it is error-prone. There should be nothing "unchecked" there. > > I don't disagree, but the use of access types should be a last resort. Again true, but IF we offer access types, THEN they must be consistent with the rest of the types system. > And > they are error-prone by definition (the only way to make them not > error-prone is to use local access types, but that assuredly finalizes > things too soon, rather than too late). Trying to make them not error-prone > is like putting wheels on a horse and calling an automobile. I don't think it is true. Access type expresses referential semantics. There are use cases where this semantics can be implemented safely. The problem with Ada's access types is that the programmer cannot influence the built-in semantics of. Instead of that special cases are mounted on: anonymous, pool-specific, null-constrained etc. Make it a proper ADT and let the programmer to deal with that mess. >> If access type had its own initialization/finalization hooks at >> appropriate places, we could move that stuff where it actually belongs to. > > Probably true, but completely irrelevant to my point. If your point is "let's get rid of access types, where possible,' then I fully agree with. But we cannot remove them altogether. So, they should be implemented at least reasonably. >>> Most of the rest of the stuff that you and Bob have talked about is too >>> incompatible to consider for Ada. >> >> I strongly disagree. I see no incompatibilities. I think that proper >> construction can be added without changing existing language behaviour. >> Even Ada.Finalization can be left as-is. > > We have proper construction. You just don't like the way it is written. > (Neither did I, initially. But it is the way it is done.) How so? There is no user-defined construction for most of the language types. In two cases where that is provided (Ada.Finalization), it is made error-prone. > And changing the place that allocated objects finalize (needed for your > access type finalization proposal) Why should it change? It is the access type object to be finalized, not the target. The finalization can collect the target object if the access type were intended to implement a GC. > or where tasks finalize (mentioned as one > of your bullets) is just too likely to break existing code. Again no. All places remain same. The difference is that user-defined hooks are called at these places. It will be possible to engage a rendezvous with a task component upon finalization, because there will be a hook called prior destruction of the object's components. I don't see why this should break anything. > I know Claw > would break badly if the latter was changed. Moreover, I recall griping > about the same problem you are complaining about vis-a-vis tasks when we > were working on Claw -- but I looked at the alternatives, and they were all > worse (much more likely to access stack objects that no longer exist, and > thus requiring overhead-increasing dynamic checks). I don't think some of > these problems are solveable within the constraints of the Ada language. > (I'd like to be proved wrong, but I'd need to see a fully worked out > proposal before I'd believe it.) I do believe that there is no problem with that. We would not change anything in the existing constructors and their behavior. We would just add appropriate calls from within. BTW, I don't propose constructors or destructors (that would be fundamentally inconsistent), I do user insertions into the existing (magically generated) constructors or destructors. That just cannot break anything. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-12 9:47 ` Dmitry A. Kazakov 2008-11-13 0:58 ` Randy Brukardt @ 2008-11-14 23:11 ` Robert A Duff 2008-11-15 10:04 ` Dmitry A. Kazakov 1 sibling, 1 reply; 40+ messages in thread From: Robert A Duff @ 2008-11-14 23:11 UTC (permalink / raw) "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote: >> Initialization: Use function calls. They work for all types. >> I think we've discussed this idea before, but I don't remember >> any fundamental problems. > > The fundamental problem is that a constructor cannot be decomposed into > functions. In the function body you have to construct the object before you > return it. Who does it and what? In Ada 2005, a constructor function creates the object via another function call, or via an aggregate, or via an uninitialized variable (to which it assigns components). > Under initialization I do not mean replacing a "default" value with > something else. I mean creation a new object (at some memory location) > initialized by a value. It had no other value before. That's exactly what a function call does: X : T := F(...); F creates a new object. In the limited case, that object _is_ X. In the nonlimited case, it gets copied into X. Either way, X has been turned from "raw bits" into an object of type T -- as you say, "it had no other value before." > Doing this by a function is semantically wrong. I agree with a lot of the rest of what you wrote, which I snipped. But I'm interested in discussing this particular point. It seems to me the whole point of functions is to create new objects. Why is this "semantically wrong"? I understand that there are tricky issues when constructing an object of a specific type and then returning it as a class-wide thing, and possibly storing pointer-to-classwide into global data structures. But I don't get what's fundamentally wrong with using functions as constructors. - Bob ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-14 23:11 ` Robert A Duff @ 2008-11-15 10:04 ` Dmitry A. Kazakov 2008-11-15 11:57 ` Programmer controlled object creation (was: Re: Ada OS based on Minix3) Georg Bauhaus 0 siblings, 1 reply; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-15 10:04 UTC (permalink / raw) On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote: > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: > >> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote: >>> Initialization: Use function calls. They work for all types. >>> I think we've discussed this idea before, but I don't remember >>> any fundamental problems. >> >> The fundamental problem is that a constructor cannot be decomposed into >> functions. In the function body you have to construct the object before you >> return it. Who does it and what? > > In Ada 2005, a constructor function creates the object via another > function call, or via an aggregate, or via an uninitialized > variable (to which it assigns components). Here we are. At the end of this chain there is always some magical construct which is not a function. It is the construct which yields the object of the type. The object is *already* constructed at this point, per magic, not per function which is not yet even returned. >> Under initialization I do not mean replacing a "default" value with >> something else. I mean creation a new object (at some memory location) >> initialized by a value. It had no other value before. > > That's exactly what a function call does: > > X : T := F(...); > > F creates a new object. In the limited case, that object _is_ X. > In the nonlimited case, it gets copied into X. Either way, > X has been turned from "raw bits" into an object of type T -- > as you say, "it had no other value before." The "value before" is one set by the magical construct used within F. The construct itself ultimately can neither be a function nor a procedure. F is a factory function, merely a wrapper around allocator and some true constructor. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Programmer controlled object creation (was: Re: Ada OS based on Minix3) 2008-11-15 10:04 ` Dmitry A. Kazakov @ 2008-11-15 11:57 ` Georg Bauhaus 2008-11-15 12:44 ` Programmer controlled object creation Dmitry A. Kazakov 0 siblings, 1 reply; 40+ messages in thread From: Georg Bauhaus @ 2008-11-15 11:57 UTC (permalink / raw) Dmitry A. Kazakov wrote: > On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote: > >> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >> >>> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote: >>>> Initialization: Use function calls. They work for all types. >>>> I think we've discussed this idea before, but I don't remember >>>> any fundamental problems. >>> The fundamental problem is that a constructor cannot be decomposed into >>> functions. In the function body you have to construct the object before you >>> return it. Who does it and what? >> In Ada 2005, a constructor function creates the object via another >> function call, or via an aggregate, or via an uninitialized >> variable (to which it assigns components). > > Here we are. At the end of this chain there is always some magical > construct which is not a function. It is the construct which yields the > object of the type. The object is *already* constructed at this point, per > magic, not per function which is not yet even returned. So what would programmer controlled object creation look like? I'm assuming you want the compiler to check that usual Ada semantics is still intact. That is, all decisions about size, alignment, placement, etc. There be partial construction, IIUC? That is, some components may be constructed late: Another function gets the partially constructed object? That is, function Make_Pizza (Hunger: Size) return Pizza; pragma Convention (Constructor, Make_Pizza); procedure Add_Topping (Object: in out Pizza; ...); -- creates a Topping component and fills it pragma Convention (Constructor, Add_Topping); type Pizza is tagged record Dough: Positive range 200 .. 1_000; Topping: ...; end record; function Make_Pizza (Hunger: Size) return Pizza is begin return Result: Pizza do -- we would NOT have an Object yet Pizza'Constructor(Dough => Grams (Hunger)); -- we may NOT have a Topping component yet Add_Topping(Result); -- pass partial object (or info about it?) -- now we have a Topping component end return; end Make_Pizza; ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Programmer controlled object creation 2008-11-15 11:57 ` Programmer controlled object creation (was: Re: Ada OS based on Minix3) Georg Bauhaus @ 2008-11-15 12:44 ` Dmitry A. Kazakov 0 siblings, 0 replies; 40+ messages in thread From: Dmitry A. Kazakov @ 2008-11-15 12:44 UTC (permalink / raw) On Sat, 15 Nov 2008 12:57:12 +0100, Georg Bauhaus wrote: > Dmitry A. Kazakov wrote: >> On Fri, 14 Nov 2008 18:11:34 -0500, Robert A Duff wrote: >> >>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes: >>> >>>> On Tue, 11 Nov 2008 17:09:54 -0500, Robert A Duff wrote: >>>>> Initialization: Use function calls. They work for all types. >>>>> I think we've discussed this idea before, but I don't remember >>>>> any fundamental problems. >>>> The fundamental problem is that a constructor cannot be decomposed into >>>> functions. In the function body you have to construct the object before you >>>> return it. Who does it and what? >>> In Ada 2005, a constructor function creates the object via another >>> function call, or via an aggregate, or via an uninitialized >>> variable (to which it assigns components). >> >> Here we are. At the end of this chain there is always some magical >> construct which is not a function. It is the construct which yields the >> object of the type. The object is *already* constructed at this point, per >> magic, not per function which is not yet even returned. > > So what would programmer controlled object creation > look like? I'm assuming you want the compiler to check > that usual Ada semantics is still intact. That is, all decisions about > size, alignment, placement, etc. > > There be partial construction, IIUC? That is, some components > may be constructed late: Another function gets the partially > constructed object? That is, > > function Make_Pizza (Hunger: Size) return Pizza; > pragma Convention (Constructor, Make_Pizza); > > procedure Add_Topping (Object: in out Pizza; ...); > -- creates a Topping component and fills it > pragma Convention (Constructor, Add_Topping); > > type Pizza is tagged > record > Dough: Positive range 200 .. 1_000; > Topping: ...; > end record; > > function Make_Pizza (Hunger: Size) return Pizza is > begin > return Result: Pizza do > -- we would NOT have an Object yet > > Pizza'Constructor(Dough => Grams (Hunger)); > -- we may NOT have a Topping component yet > > Add_Topping(Result); > -- pass partial object (or info about it?) > > -- now we have a Topping component > end return; > end Make_Pizza; Nothing like that. A proposal was posted long ago: http://groups.google.de/group/comp.lang.ada/browse_frm/thread/72c34c66b38e0e05?ie=UTF-8&oe=utf-8 The proposed sugar for constraints evaluation and construction hooks was: function Pizza'Get_Constraints (...) return Pizza'Constraints; procedure Pizza'Initialize (X : in out Pizza; ...); The proposal contained examples of how the components become their constraints from the parameters of a factory function. Of course there was no such thing like partially constructed components. BTW, it is Ada 2005 new feature that allows something like partial construction: function Make return T is begin return R : T do ... raise I_Do_Not_Like_It; end return; exception when I_Do_Not_Like_It => return R : T do ... end return; end Make; Here the result is constructed twice. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-10 8:12 ` Ivan Levashew 2008-11-10 8:58 ` Dmitry A. Kazakov @ 2008-11-10 10:18 ` Georg Bauhaus 1 sibling, 0 replies; 40+ messages in thread From: Georg Bauhaus @ 2008-11-10 10:18 UTC (permalink / raw) Ivan Levashew schrieb: > Two general problems of starting an enterprise Ada project are as > follows: > Lack of libraries > Lack of developers > > While you can do little about the second, you can at least do binding > generators. Bindings work in a practical sense but they can only perpetuate the lack of integration at another level, the level of objects. I understand there are at least these approaches: - CORBA and the like - .NET style type libraries - OO ABI integration What these approaches have in common could be condensed into some sort of pragma Abstract_Machine, in the sense of the B method. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock ` (2 preceding siblings ...) 2008-11-10 8:12 ` Ivan Levashew @ 2008-11-11 1:00 ` Freejack 2008-11-11 8:32 ` Martin Krischik 4 siblings, 0 replies; 40+ messages in thread From: Freejack @ 2008-11-11 1:00 UTC (permalink / raw) Cedric.Lannock wrote: > Hi all, > > I came across Ada at the beginning of the year and read quite a few > books about Ada. A few month later I joined a Linux workgroup within a > local computer association. This way I learned about Ada and had a > look into Tanenbaum's book on operating systems (http://www.amazon.com/ > Operating-Systems-Implementation-Prentice-Software/dp/0131429388/ > ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1226066518&sr=8-1) and Minix 3 > (http://www.minix3.org/). > > I thought about an operating system written fully in Ada. When surfing > the net I came across the various discussions about that subject. > > What taking the Minix 3 system as basis for porting it to Ada? The > Minix 3 is a modern micro kernel os and has about 4.000 Lines of code. > It is full Posix compatible. Some guys have added real time > functionality to it (see ACM.org for further reading). Thus it would a > good place to start. As it has to few lines of code it should be > possible to build a kernel in overseeable time. > > Another thought to get this project taking some speed would be not to > rewrite all the available C code but to develop a translator c2ada. It > would us getting startet and the resulting code could be enhanced and > improved. > > Do you think this would make this project doable? > > Regards > > Cedric Lannock A better approach, in my humble opinion, would be start with an existing kernel and expand outward. For the longest time I've been thinking about making a Ravenscar Linux Kernel Runtime Module. From there it could be expanded to include a full Ada Runtime Environment, add an ABI, it's own System Calls, etc... gradually replacing the functionality of the existing kernel, while adding it's own OO functionality. With this approach, you get an active test platform, access to an "interface" that most developers are already familiar with(i.e. Posix), while having the ability to gradually add more extensive non-posix features to the platform. I'm certain the additional OO features will attract users of other High Level language tools(Java, Haskell, OCaml, etc..), at the same time it wouldn't alienate users of the more common "system level" language tools(C, Assembler, Fortran, etc...). Gradually, as more OO and Functional "paradigm"(I hate that word) features are added, developers will begin to test, work with, and use those features in thier userspace apps. It really only takes a few developers to get a Kernel Module started and working. The OpenRavenscar project has already done alot of the work for us. What do you guys think? dimonax ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock ` (3 preceding siblings ...) 2008-11-11 1:00 ` Freejack @ 2008-11-11 8:32 ` Martin Krischik 2008-11-11 11:09 ` Peter C. Chapin 4 siblings, 1 reply; 40+ messages in thread From: Martin Krischik @ 2008-11-11 8:32 UTC (permalink / raw) Cedric.Lannock schrieb: > Do you think this would make this project doable? I was following the discussion for quite a while now and where left with and important questions which you should ask yourself: Which hardware should your OS run on? If you need to reboot your computer for every test run it will slow you down. The answer is also important if you want other to try out you work. BeOS only became slightly successful after it was ported to standard PC hardware. (Not that I like standard PC hardware all that much). Now, if I wanted to create an OS I would not target real hardware at all. At least not in the beginning. I would probably implement the OS inside a VMware virtual machine. VMware would mean that my OS could be tries out on a Windows / Linux / Mac OS System with out and repartition pain. Actually one could a ready made create VMWare payer image significantly reducing the try out or join the project hurdle. Regards Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 8:32 ` Martin Krischik @ 2008-11-11 11:09 ` Peter C. Chapin 2008-11-11 11:59 ` Georg Bauhaus 2008-11-13 6:48 ` Martin Krischik 0 siblings, 2 replies; 40+ messages in thread From: Peter C. Chapin @ 2008-11-11 11:09 UTC (permalink / raw) Martin Krischik wrote: > Now, if I wanted to create an OS I would not target real hardware at > all. At least not in the beginning. I would probably implement the OS > inside a VMware virtual machine. What about targeting a hypervisor like Xen? If I understand correctly (and I may not) that would separate the OS somewhat from the real hardware and may help its portability in the long run. Peter ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 11:09 ` Peter C. Chapin @ 2008-11-11 11:59 ` Georg Bauhaus 2008-11-11 14:35 ` Ludovic Brenta 2008-11-13 7:01 ` Martin Krischik 2008-11-13 6:48 ` Martin Krischik 1 sibling, 2 replies; 40+ messages in thread From: Georg Bauhaus @ 2008-11-11 11:59 UTC (permalink / raw) Peter C. Chapin schrieb: > Martin Krischik wrote: > >> Now, if I wanted to create an OS I would not target real hardware at >> all. At least not in the beginning. I would probably implement the OS >> inside a VMware virtual machine. > > What about targeting a hypervisor like Xen? If I understand correctly > (and I may not) that would separate the OS somewhat from the real > hardware and may help its portability in the long run. How could separation from the hardware do better than a Microkernel such as Minix 3? Full virtualization also deprives you of access to a larger set of hardware. Which, I'd speculate, is not too helpful when targetting mostly embedded system? ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 11:59 ` Georg Bauhaus @ 2008-11-11 14:35 ` Ludovic Brenta 2008-11-11 16:49 ` Georg Bauhaus 2008-11-13 7:10 ` Martin Krischik 2008-11-13 7:01 ` Martin Krischik 1 sibling, 2 replies; 40+ messages in thread From: Ludovic Brenta @ 2008-11-11 14:35 UTC (permalink / raw) Georg Bauhaus wrote: > Peter C. Chapin schrieb: > > Martin Krischik wrote: > >>> Now, if I wanted to create an OS I would not target real hardware at >>> all. At least not in the beginning. I would probably implement the OS >>> inside a VMware virtual machine. > >> What about targeting a hypervisor like Xen? If I understand correctly >> (and I may not) that would separate the OS somewhat from the real >> hardware and may help its portability in the long run. > > How could separation from the hardware do better than a > Microkernel such as Minix 3? > > Full virtualization also deprives you of access to > a larger set of hardware. Which, I'd speculate, is not > too helpful when targetting mostly embedded system? Georg, how do you know the OP wants to target embedded systems? I personally think targetting Xen is a nice long-term goal because it is unrealistic to think people will run an Ada operating system on a dedicated machine. However, requiring that developers use and develop on Xen might hinder adoption. It is better to do the initial development targetting qemu or equivalent because, as Georg mentioned, it lowers the barrier for contributors. After the kernel boots and gains critical mass (i.e. becomes usable), comes time to think about Xen and real hardware. BTW, this is exactly what Lovelace does -- hint, hint :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 14:35 ` Ludovic Brenta @ 2008-11-11 16:49 ` Georg Bauhaus 2008-11-13 7:10 ` Martin Krischik 1 sibling, 0 replies; 40+ messages in thread From: Georg Bauhaus @ 2008-11-11 16:49 UTC (permalink / raw) Ludovic Brenta schrieb: > Georg, how do you know the OP wants to target embedded systems? I don't know, it seems reasonable, though, to assume embedded systems here because Minix 3 announcements say it is being made suitable for small, embeddable systems: "MINIX 3 adds the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability" (minix3.org) Thinking again, though, if I'd want to offload the portability work to a non-Ada layer below an Ada kernel, e.g. Xen etc. block drivers, the interesting plan that Dmitry Kazakov has laid out might have a better chance, as there is more time to concentrate on an OS featuring a better API. (E.g. modules, not functions). And, you're right, results might be usable earlier, provided there is more hardware supporting Xen drivers than original drivers. (Incidentally, it is possible to run Minix 3 on VMWare Workstation. I needed to select to a version 5 virtual machine, though.) ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 14:35 ` Ludovic Brenta 2008-11-11 16:49 ` Georg Bauhaus @ 2008-11-13 7:10 ` Martin Krischik 1 sibling, 0 replies; 40+ messages in thread From: Martin Krischik @ 2008-11-13 7:10 UTC (permalink / raw) Hi Ludovic, Ludovic Brenta schrieb: > Georg Bauhaus wrote: >> Peter C. Chapin schrieb: >>> Martin Krischik wrote: >>>> Now, if I wanted to create an OS I would not target real hardware at >>>> all. At least not in the beginning. I would probably implement the OS >>>> inside a VMware virtual machine. >>> What about targeting a hypervisor like Xen? If I understand correctly >>> (and I may not) that would separate the OS somewhat from the real >>> hardware and may help its portability in the long run. >> How could separation from the hardware do better than a >> Microkernel such as Minix 3? >> >> Full virtualization also deprives you of access to >> a larger set of hardware. Which, I'd speculate, is not >> too helpful when targetting mostly embedded system? > > Georg, how do you know the OP wants to target embedded systems? > > I personally think targetting Xen is a nice long-term goal because it > is unrealistic to think people will run an Ada operating system on a > dedicated machine. However, requiring that developers use and develop > on Xen might hinder adoption. It is better to do the initial > development targetting qemu or equivalent because, as Georg mentioned, > it lowers the barrier for contributors. Actually that was me who suggested it. qemu sound good, supports the 3 important OS and ready made disk images for "quick install and try out". Regards Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 11:59 ` Georg Bauhaus 2008-11-11 14:35 ` Ludovic Brenta @ 2008-11-13 7:01 ` Martin Krischik 1 sibling, 0 replies; 40+ messages in thread From: Martin Krischik @ 2008-11-13 7:01 UTC (permalink / raw) Hi Georg, Georg Bauhaus schrieb: > Peter C. Chapin schrieb: >> Martin Krischik wrote: >> >>> Now, if I wanted to create an OS I would not target real hardware at >>> all. At least not in the beginning. I would probably implement the OS >>> inside a VMware virtual machine. >> What about targeting a hypervisor like Xen? If I understand correctly >> (and I may not) that would separate the OS somewhat from the real >> hardware and may help its portability in the long run. > How could separation from the hardware do better than a > Microkernel such as Minix 3? Speaking of Microkernel: what ever happened to the ring concept? Why this all (ring 0) and nothing (ring 3) everywhere? After all one of the most stable OS's - ever - used 4 privilege modes: http://en.wikipedia.org/wiki/VAX#Privilege_Modes privilege mode. Interesting to see that the File System runs in it's own mode - especially when one considers the recent FUSE development. Using 4 privilege modes certainly would be something I would investigate when trying out OS design. > Full virtualization also deprives you of access to > a larger set of hardware. Which, I'd speculate, is not > too helpful when targeting mostly embedded system? Actually I see the "larger set of hardware" as a disadvantage for a new OS. For a small OS with a few or only one developers the is just not enough horse power to produce tons and tons of different device driver. With full virtualization you just have one set of hardware to produce device driver for which leaves you with more time for the interesting things like new revolutionary OS design. Regards Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-11 11:09 ` Peter C. Chapin 2008-11-11 11:59 ` Georg Bauhaus @ 2008-11-13 6:48 ` Martin Krischik 2008-11-13 8:09 ` Thomas Locke 1 sibling, 1 reply; 40+ messages in thread From: Martin Krischik @ 2008-11-13 6:48 UTC (permalink / raw) Peter C. Chapin schrieb: > Martin Krischik wrote: > >> Now, if I wanted to create an OS I would not target real hardware at >> all. At least not in the beginning. I would probably implement the OS >> inside a VMware virtual machine. > > What about targeting a hypervisor like Xen? If I understand correctly > (and I may not) that would separate the OS somewhat from the real > hardware and may help its portability in the long run. I knew that this question would come ;-) - The answer is simple: Xen is not available for Window and Mac OS X hosts - together they amount to 90% of all desktop OS. While Ada programmer are not like the average user and are more likely to use Linux shutting out Windows and Mac OS X would still shut out a lot of potential users and beta testers. And even on Linux it is not all that easy. I can install a VMware Player in no time on Linux but never quite succeeded in getting Xen to work. Even with SuSE Linux which comes with a Xen plug-in for Yast. So in short: Xen is not all that portable and would defeat the "quit install and try it out" objective. Regards Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-13 6:48 ` Martin Krischik @ 2008-11-13 8:09 ` Thomas Locke 2008-11-13 10:16 ` Alex R. Mosteo 0 siblings, 1 reply; 40+ messages in thread From: Thomas Locke @ 2008-11-13 8:09 UTC (permalink / raw) Martin Krischik wrote: > I knew that this question would come ;-) - The answer is simple: Xen is > not available for Window and Mac OS X hosts - together they amount to > 90% of all desktop OS. > > While Ada programmer are not like the average user and are more likely > to use Linux shutting out Windows and Mac OS X would still shut out a > lot of potential users and beta testers. > > And even on Linux it is not all that easy. I can install a VMware Player > in no time on Linux but never quite succeeded in getting Xen to work. > Even with SuSE Linux which comes with a Xen plug-in for Yast. How about Virtualbox then: http://www.virtualbox.org/wiki/Downloads It's fairly light, supports a wide range of platforms, there's an OS edition, and it works extremely well. I can highly recommend Virtualbox, and I've only been using it for a few months. I moved to Virtualbox from VMware. I find that Virtualbox is easier to get going (running Slackware 12.1), lighter on resources and faster. It's basically just a very nice piece of software. Oh, and the docs are quite extensive, which is very nice. :o) /Thomas ^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Ada OS based on Minix3 2008-11-13 8:09 ` Thomas Locke @ 2008-11-13 10:16 ` Alex R. Mosteo 0 siblings, 0 replies; 40+ messages in thread From: Alex R. Mosteo @ 2008-11-13 10:16 UTC (permalink / raw) Thomas Locke wrote: > Martin Krischik wrote: >> I knew that this question would come ;-) - The answer is simple: Xen is >> not available for Window and Mac OS X hosts - together they amount to >> 90% of all desktop OS. >> >> While Ada programmer are not like the average user and are more likely >> to use Linux shutting out Windows and Mac OS X would still shut out a >> lot of potential users and beta testers. >> >> And even on Linux it is not all that easy. I can install a VMware Player >> in no time on Linux but never quite succeeded in getting Xen to work. >> Even with SuSE Linux which comes with a Xen plug-in for Yast. > > How about Virtualbox then: > > http://www.virtualbox.org/wiki/Downloads > > It's fairly light, supports a wide range of platforms, there's an OS > edition, and it works extremely well. > > I can highly recommend Virtualbox, and I've only been using it for a few > months. I moved to Virtualbox from VMware. I find that Virtualbox is > easier to get going (running Slackware 12.1), lighter on resources and > faster. It's basically just a very nice piece of software. > > Oh, and the docs are quite extensive, which is very nice. Using VBox here too, is a great piece of software. And, if I'm not mistaken, the virtualization part is (or started being) basically qemu's, so the emulated hardware may still be the same, and you'd get two birds in a shot. ^ permalink raw reply [flat|nested] 40+ messages in thread
end of thread, other threads:[~2008-11-15 12:44 UTC | newest] Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-07 14:10 Ada OS based on Minix3 Cedric.Lannock 2008-11-07 16:20 ` xavier grave 2008-11-08 3:46 ` anon 2008-11-10 8:12 ` Ivan Levashew 2008-11-10 8:58 ` Dmitry A. Kazakov 2008-11-10 9:26 ` Ivan Levashew 2008-11-10 10:11 ` Georg Bauhaus 2008-11-10 10:24 ` Jacob Sparre Andersen 2008-11-10 10:51 ` Dmitry A. Kazakov 2008-11-10 11:07 ` Ludovic Brenta 2008-11-10 11:42 ` Ivan Levashew 2008-11-10 12:04 ` Ludovic Brenta 2008-11-11 22:16 ` Robert A Duff 2008-11-12 6:28 ` Ivan Levashew 2008-11-10 10:50 ` Ivan Levashew 2008-11-10 11:01 ` Dmitry A. Kazakov 2008-11-10 15:31 ` Robert A Duff 2008-11-10 15:56 ` Dmitry A. Kazakov 2008-11-11 22:09 ` Robert A Duff 2008-11-12 9:47 ` Dmitry A. Kazakov 2008-11-13 0:58 ` Randy Brukardt 2008-11-13 17:28 ` Dmitry A. Kazakov 2008-11-13 23:25 ` Randy Brukardt 2008-11-14 9:30 ` Dmitry A. Kazakov 2008-11-14 23:11 ` Robert A Duff 2008-11-15 10:04 ` Dmitry A. Kazakov 2008-11-15 11:57 ` Programmer controlled object creation (was: Re: Ada OS based on Minix3) Georg Bauhaus 2008-11-15 12:44 ` Programmer controlled object creation Dmitry A. Kazakov 2008-11-10 10:18 ` Ada OS based on Minix3 Georg Bauhaus 2008-11-11 1:00 ` Freejack 2008-11-11 8:32 ` Martin Krischik 2008-11-11 11:09 ` Peter C. Chapin 2008-11-11 11:59 ` Georg Bauhaus 2008-11-11 14:35 ` Ludovic Brenta 2008-11-11 16:49 ` Georg Bauhaus 2008-11-13 7:10 ` Martin Krischik 2008-11-13 7:01 ` Martin Krischik 2008-11-13 6:48 ` Martin Krischik 2008-11-13 8:09 ` Thomas Locke 2008-11-13 10:16 ` Alex R. Mosteo
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox