Re: Advantage of XML based GUI? (was Re: Ada-inspired OS/Language)

[nickroberts@blueyonder.co.uk (Nick Roberts)]

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