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.4 required=5.0 tests=AC_FROM_MANY_DOTS,BAYES_00 autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,216b18d81cce4f75 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-07-02 07:07:01 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!193.251.151.101!opentransit.net!fr.clara.net!heighliner.fr.clara.net!isdnet!psinet-france!psiuk-f4!psiuk-p4!uknet!psiuk-n!news.pace.co.uk!nh.pace.co.uk!not-for-mail From: "Marin David Condic" Newsgroups: comp.lang.ada Subject: Re: Ada Microkernel? Date: Mon, 2 Jul 2001 09:50:50 -0400 Organization: Posted on a server owned by Pace Micro Technology plc Message-ID: <9hpu7s$7g7$1@nh.pace.co.uk> References: <%3H_6.416$Kf3.3173@www.newsranger.com> <9hfgrm$ngd$1@nh.pace.co.uk> <3B3B6D4C.5DEC7D52@online.no> <9hfv15$s59$1@nh.pace.co.uk> <9hfvo1$sbd$1@nh.pace.co.uk> <9hhv2m$ivm$1@nh.pace.co.uk> <4J0%6.1684$Kf3.17425@www.newsranger.com> <9hi6fv$lop$1@nh.pace.co.uk> NNTP-Posting-Host: 136.170.200.133 X-Trace: nh.pace.co.uk 994081852 7687 136.170.200.133 (2 Jul 2001 13:50:52 GMT) X-Complaints-To: newsmaster@pace.co.uk NNTP-Posting-Date: 2 Jul 2001 13:50:52 GMT X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Xref: archiver1.google.com comp.lang.ada:9332 Date: 2001-07-02T13:50:52+00:00 List-Id: The key to it is predictability. Or at least uniformity so you know that your timing tests are going to be good. One could argue all day about this OS versus that OS and their relative suitability for realtime work, but I think that to be a candidate at all, the OS has to provide deterministic behavior and stability. How compatible is this with the goals of a "workstation" OS? I don't know. I think that from a requirements viewpoint, one might insist that a single process should be able to run in some mode where it can guarantee that its cycle time is 100% consistent. (You could ask if this is with or without threads within the process - I'd think we would want that.) As long as the OS will let the process run in a guaranteed consistent cycle time, the rest is just efficiency and appropriate hardware to make sure the cycle time is sufficiently fast. AFAIK, the two things that this would impact the most would be the scheduler and the device driver model (interrupt handling figuring into the device driver model as far as I'm concerned.) If you had at the core of your OS these two things built such that they were suitable for realtime, you'd have something that could be marketed in a large variety of places. If you could build a workstation OS on top of that - even if it had to have some different operation mode - you'd have an environment that was quite valuable for realtime/embedded development, for reasons that should be obvious. Can an OS provide at least one "realtime" process and still allow other processes to run in an acceptable manner? I don't know if this is doable, but it would certainly be cool if it did exist. I'd even accept some sort of configuration switch at boot time or OS build time just so you could have essentially the same OS on your PC as would be used in the realtime/embedded app. That enables a huge amount of development to occur on the desktop rather than the lab - at an enormous cost/time savings. MDC -- Marin David Condic Senior Software Engineer Pace Micro Technology Americas www.pacemicro.com Enabling the digital revolution e-Mail: marin.condic@pacemicro.com Web: http://www.mcondic.com/ "Ted Dennison" wrote in message news:wG3%6.1950$Kf3.21097@www.newsranger.com... > In article <9hi6fv$lop$1@nh.pace.co.uk>, Marin David Condic says... > > For schedulability analysis, I presume one would handle this either by adding > the appropriate multiple of the max scheduling delay (which the OS vendor would > hopefully provide), or by showing that the task in question completes in less > than one scheduling interval. Being able to provide that max scheduling delay > (and have it be a resonable number) is where I think most consumer OS's would > have trouble. >