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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,55958fd991db66fe X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-09-13 12:55:32 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!fu-berlin.de!uni-berlin.de!pc-62-31-50-169-cr.blueyonder.co.UK!not-for-mail From: nickroberts@blueyonder.co.uk (Nick Roberts) Newsgroups: comp.lang.ada Subject: Re: Advantage of XML based GUI? (was Re: Ada-inspired OS/Language) Date: Fri, 13 Sep 2002 19:55:58 GMT Organization: AdaOS Message-ID: <3d823c58.1092492730@news.cis.dfn.de> References: <4519e058.0209101828.cb5ff85@posting.google.com> <3d7f9d3f.920665532@news.cis.dfn.de> <3d80b566.992395741@news.cis.dfn.de> <3d81400c.1027894993@news.cis.dfn.de> <2nbgXSBE2fdF@eisner.encompasserve.org> NNTP-Posting-Host: pc-62-31-50-169-cr.blueyonder.co.uk (62.31.50.169) X-Trace: fu-berlin.de 1031946931 1135554 62.31.50.169 (16 [25716]) X-Newsreader: Forte Free Agent 1.21/32.243 Xref: archiver1.google.com comp.lang.ada:28951 Date: 2002-09-13T19:55:58+00:00 List-Id: On 13 Sep 2002 11:00:18 -0600, Kilgallen@SpamCop.net (Larry Kilgallen) strongly typed: >In article <3d81400c.1027894993@news.cis.dfn.de>, nickroberts@blueyonder.co.uk (Nick Roberts) writes: >> On 12 Sep 2002 11:23:11 -0600, Kilgallen@SpamCop.net (Larry Kilgallen) >> strongly typed: > >>>Existing device drivers that follow what model ? >> >> Various and many. Maybe Linux. Maybe Windows. Probably a good plan would be >> to start with one that is relatively simple (but still works), and work >> towards the more sophisticated ones. > >I believe such an approach would lead to a "tacked on" result such >as Windows NT, 2000, etc., with GUI from one heritage tacked onto an >operating system kernal from another. Yes indeed, I quite agree. It would be 'handy' to be able to import foreign device drivers, but certainly not ideal. Ideally, our device drivers would all be written natively for AdaOS. >>>Certainly that is fundamental to the design of the "native" device >>>driver system. >> >> A device driver may require: port I/O; memory mapped I/O; interrupt handler >> installation (and communication); communication with higher levels of >> software. What else? The design of AdaOS is very flexible. I suspect most >> DD environments would fit into AdaOS with little difficulty. > >A Port and Class driver architecture, allowing in the simplest case >multiple drivers to share a single SCSI bus and in more complex cases >multiple ports to access the same device on a remote controller. This sounds like the kind of situation where one needs to 'fake' hardware, by facilitating virtual ports and interrupts. I'm sure this could be added to Bachar (the AdaOS microkernel) very readily. >For a sanity check, I would suggest desk checking any design against >contemporary Fibre Channel hardware specifications to ensure that >IO to a specified disk can be handled over multiple paths. Okay. >>>Unless you design it from the start, for instance, >>>it would be difficult to deliver ASTs. >> >> What is an 'AST' in this context, please? > >Execution of code provided by the user, in user process context and >user processor mode when an IO request completes, independent of the >normal code flow of the user program. The Bachar microkernel provides exactly this capability in two ways: a privileged process is permitted to convert a thread into an interrupt service routine; a thread can 'generate an exception' in another thread (within the same process). So "no problemo", I think! >====================== > >Of course I can only mention considerations I know about, I am sure >there are others with experience in other environments (IBM Parallel >sysplex, etc.) who should be consulted to understand high end device >driver environments. In any event, I have designed Bachar (and other AdaOS bits) to be extremely future-proof, so that if it becomes necessary to add special functionality (to accomodate special hardware, for example), it should be relatively painless to do it. -- Nick Roberts