From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,b95a522100671708 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: For the AdaOS folks Date: Mon, 3 Jan 2005 11:30:29 +0100 Organization: cbb software GmbH Message-ID: <1cza5d5x7snmd.lr7wfm9fdsvd.dlg@40tude.net> References: <1PTAd.1218$0y4.421@read1.cgocable.net> <1vemlj8wqr9ea$.qyecszhsmtqa$.dlg@40tude.net> <1b48kdfqsk3mw.7gajq12fsa82.dlg@40tude.net> <52fBd.42256$nV.1324414@news20.bellglobal.com> <_gHBd.14666$0y4.10314@read1.cgocable.net> <8rz51zshvp8k$.gvir0kpiedzk.dlg@40tude.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: individual.net HXCvytT9IPkM4TVuRWP6FAVIg8/Ey9O+MZ3SexN/ipuJVaGro= User-Agent: 40tude_Dialog/2.0.12.1 Xref: g2news1.google.com comp.lang.ada:7402 Date: 2005-01-03T11:30:29+01:00 List-Id: On Sun, 02 Jan 2005 17:04:29 -0500, Warren W. Gay VE3WWG wrote: > Dmitry A. Kazakov wrote: >> On Sat, 01 Jan 2005 19:31:56 -0500, Warren W. Gay VE3WWG wrote: >> Where is any problem? If the kernel provides persistence and your >> application needs, say an integer parameter. Derive from the base >> Application_Data_Type add a field, here you are. > > The problem is where is the improvement over the registry > API that says create/delete an integer? What if my application needs My_Fancy_Type, soundtrack of James Bond and another application? > Put your own OO framework around it if that's what you want. It is Turing complete, I know! (:-)) >> Yes it is. You have to know the names you are looking for! The first step >> is of course to define some naming convention. This is a bad way, because >> it is not enforced. See what happens with /etc and HKEY_LOCAL_MACHINE. So >> the second step is to provide API to query that names from an application. >> But that is still not good. A better way, as I said, is OO. You ask an >> application: give me your settings and the result is an object of those. >> The last step is to ask yourself what for? There is GNAT, an object why >> cannot I talk to it directly? > > And how do your identify your GNAT object? At the end of the day, > you still have to grapple with "names" and "identities". Only > the details change. The "detail" is that you identify not some GNAT installation file #1534, but GNAT. GNAT itself is easy to find, its components are not. They may vary from version to version. It is GNAT's responsibility to know them, not of GNAT user. >> Why there should be any pathnames? A name is used only to get an object >> from a text map, provided that there should be one. > > So just how do you expect to identify what piece of software > you want to know about, without using a name (or identity if > you prefer)? OO doesn't do away with this requirement. ADT allows to organize it in a proper way. We are using types to forget about bytes. In OSes we are still using "bytes" = files. >> Did UNIX care much about Ada? We'll make them see! (:-)) > > The only problem with that is that you can make things hard for > yourself. For example, I have no grand plans that I or anyone > else I know, is going to convert the X-Window system to MyOS > anytime soon. The best compromise is to allow an optional POSIX > module on top of the mk, working with MyOS, to make it easy to > port the X-Window system, if that's what I want. GNAT/GCC is > another motive in that direction. X11 and GCC are just applications. GNAT needs text files. Let you have an Ada_Source object derived from what I know. Somewhere you will also have Abstract_Text_Stream. If Ada_Source is not already a descendant of Abstract_Text_Stream then derive a new type from both. End of story. Ada run-time is another issue. I suppose you'd better have OS-native tasking than tunnel it through POSIX. After all, it was you who started APQ instead of using ODBC, did you? (:-)) >> As you probably saw, I do not want to build a fat sandwich >> OO-interface->procedural API->OO-kernel. It clumsy, ugly, buggy and >> inefficient. I want to directly talk to OS. > > A couple of things. First of all, most microkernels that I am > aware of (or at least the ones I plan to use), all use a > procedural API (albeit with handles, if you want to call > them that). > > Using a Mach type of approach, you write a bunch of executables > that behave as "servers". Application programs become "clients" > of these. This leaves the interface between the client user > mode program and the server(s), as a RPC API interface set. > > Now MyOS (I'll just use that for example), would then of > course sport a nice native Ada interface for application > programs. However, underneath this "binding" (which is what > it really is), it will be calling an RPC message API that is > supported by the procedural API microkernel. > > User-mode-client-OO->Ada Binding->RPC->Server(s)->microkernel > > Can native objects be exported from operating systems? A > quick survey produces this list: > > - integer file descriptor (POSIX) > - handles (Windows) > - ports (Mach) > - identities (L4) > - ipc ID (UNIX SysV) for message queues, shared mem etc. > > These are all fancy "handles" of one sort or another. You won't > get much more than that from any O/S. Why? How do you share an > object in protected-mode with a user-mode process? You can't. > Even if you could, there would be parts of objects that the > O/S wouldn't want you to mess with, or perhaps even look at. > Maybe you can't because the object is just a Mach port. > > The best API answer seems to be to just provide a handle that > can be used to refer to the object (like an Ada access type), > or in the case of a Mach port, be the object metaphore. Then > you call varied API set (effectively methods) on that object, > using the given handle(s). It is not like Ada access type, because handle is not a pointer. It is a key in some associative array. To "dereference" it you have to switch to supervisor mode. Then you have to check it, because somebody could mess with its value etc. It is very inefficient. You have to do all this even if you call a function of a protected object, which could be safely performed in user-mode. BTW, the very notion of user-mode is also of old procedural fashion. A protected object is passive. You should be able to access it in any "mode". But when you want to queue to its entry or to call its procedure, only then you have to switch the context to make the object data available to write. It is not kernel business anymore. Your RPC services is another model. They are monitors. These can be exposed in API as tasks to have rendezvous with. Again OO/ADT could bring great advantages here. Imagine extensible tasks. Presently, if you have some sequence of actions to be performed on one service, you have to care about locking, serializing, then you implement it as separate inefficient RPCs to the server. Service extensions would be sort of stored procedures in DB terms. > Then if you want it to look different than that, you provide > a binding. The general idea however, is that an Ada based > O/S will have native bindings. The packages won't be > adaptations of C header files etc. OK, but that is more like C programming in Ada to me. This new OS will not become a breakthrough. It will be a stable decent OS, but who needs that? See what happened with VMS? The only way to kill the Windows/UNIX monster to offer something really revolutionary. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de