Ada OS Kernel features

["Brian Catlin" <briancatlin@mindspring.com>]

What sort of features would be desirable/required in the kernel?

Processor architectures:
  What sort of processor architectures should be supported?  32-bit obviously,
but what about 64-bit, or 16-bit?  Little-endian only, or big-endian too?
(personally, I view big-endian as a crime against nature, and would vote against
it - besides there are not many of them out there compared to little-endian
processors)  Deciding on these issues early is very important, as it will
greatly influence the rest of the design and implementation of the kernel.  All
the candidate processors need to be examined, and the features that are present
in all (and all subsequent architectures that will be supported) need to be
identified.  Processors that do not implement certain required features must be
able to emulate these features in software, or the processor cannot be
supported.

Scheduler:
  I think that the kernel should support three types of tasks: isochronous,
real-time, and general purpose.  An isochronous task is a periodic time-driven
task with performance requirements for bounded latency and jitter, and
guaranteed throughput.  A real-time task has performance requirements for low
latency and high throughput.  Both isochronous and real-time tasks have bounded
execution times, so that the system can bound latency and jitter for other such
tasks.  In contrast, a general purpose task is characterized by lengthy or
unbounded execution time, and may not have strict requirements for latency or
throughput; however, the system does guarantee some progress for such tasks.
Tasks should be grouped into processes.

Symmetric multi-processing:
  This is the same capability general-purpose operating systems such as NT, VMS,
etc. have.  Each processor is of the same type, and has the same view of memory.
It then becomes irrelevant which processor is running a particular task.

Synchronization primitives:
  How will tasks synchronize with each other?  Synchronization of tasks within
the same process can use existing Ada methods; but what about tasks in different
processes, or on different processors?  What about application written in
languages other than Ada?

Memory management:
  A demand-paged memory manager would seem to be required.  However, I would not
like to see paging made a requirement - as long as there is enough physical
memory, there should be no need.  This would allow the operating system to be
tailored to run on a very small diskless system.  It is the memory manager that
really differentiates one process from another, by providing a unique address
space that is unreachable by any other process.  The memory manager should
support sharing pages between processes to facilitate fast inter-process
communications.  Mapping a file on the disk directly into a range of addresses
in a process would also be a big benefit: all disk reads and writes would be
implemented as reads and writes to a process' address space.

File system cache:
  What sort of file system cache would be appropriate?  A logical block cache
uses much less memory than a virtual block cache, but the virtual block cache
has the ability to read ahead.  A logical block cache will cache the blocks on a
disk (or partition) _after_ an application has already read them in.  A logical
block cache knows nothing about files.  A virtual block cache will cache blocks
in a file, which allows read ahead (because the next blocks in a file will
always be known).

I/O subsystem:
  What form are drivers to take?  A packet-driven system would seems to provide
the best performance.  In a packet-driven I/O system, a context block (generally
referred to as an IRP (I/O Request Packet)) containing all the information to
process an I/O request is passed around between drivers.  What form should a
driver take?  Implementing a driver as one or more tasks in the kernel seems to
be the most natural.  The layering of device drivers (as implemented) in NT
would also seem to be a very valuable feature.

 -Brian