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=0.6 required=5.0 tests=BAYES_00,TO_NO_BRKTS_FROM_MSSP autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6394e5e171f847d1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-09-05 07:04:33 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!feed.textport.net!newsranger.com!www.newsranger.com!not-for-mail Newsgroups: comp.lang.ada From: Ted Dennison References: <9n4euv$t9m$1@slb6.atl.mindspring.net> Subject: Re: Ada OS Kernel features Message-ID: X-Abuse-Info: When contacting newsranger.com regarding abuse please X-Abuse-Info: forward the entire news article including headers or X-Abuse-Info: else we will not be able to process your request X-Complaints-To: abuse@newsranger.com NNTP-Posting-Date: Wed, 05 Sep 2001 10:04:26 EDT Organization: http://www.newsranger.com Date: Wed, 05 Sep 2001 14:04:26 GMT Xref: archiver1.google.com comp.lang.ada:12749 Date: 2001-09-05T14:04:26+00:00 List-Id: In article <9n4euv$t9m$1@slb6.atl.mindspring.net>, Brian Catlin says... >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 Interesting. I've never seen them broken out that way. Is that a typical way of thinking about real-time tasks these days? In fact, I have trouble finding good references for dealing with RT tasks that have jitter requirements. As near as I can tell, any such task has to be scheduled in such a way that it is the first task to get run after its designated clock tick. Obviously this means you can't create a whole lot of these... >be the most natural. The layering of device drivers (as implemented) in NT >would also seem to be a very valuable feature. I've started to look at NT drivers recently. I do think thier layered approach is a cool idea, but I have one major problem with it. There doesn't appear to be any good reason to require any but the lowest-level driver to run in kernel mode (ring 3, supervisor, whatever you call it...) Such programs are much tougher to debug, and bugs in them are much more catastrophic. It appears that they are just having them run in kernel mode because that's what device drivers are supposed to do. --- T.E.D. homepage - http://www.telepath.com/dennison/Ted/TED.html home email - mailto:dennison@telepath.com