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,XPRIO autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6394e5e171f847d1,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-04 22:59:04 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!feed2.news.rcn.net!rcn!newsfeed1.earthlink.net!newsfeed2.earthlink.net!newsfeed.earthlink.net!news.mindspring.net!not-for-mail From: "Brian Catlin" Newsgroups: comp.lang.ada Subject: Ada OS Kernel features Date: Tue, 4 Sep 2001 22:58:52 -0700 Organization: Sannas Consulting Message-ID: <9n4euv$t9m$1@slb6.atl.mindspring.net> NNTP-Posting-Host: a5.f7.ed.41 X-Server-Date: 5 Sep 2001 05:58:55 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Xref: archiver1.google.com comp.lang.ada:12732 Date: 2001-09-05T05:58:55+00:00 List-Id: 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