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 autolearn=ham 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 23:48:58 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!148.122.208.68!news2.oke.nextra.no!nextra.com!news1.oke.nextra.no.POSTED!not-for-mail Sender: ohk@maestro.clustra.com Newsgroups: comp.lang.ada Subject: Re: Ada OS Kernel features References: <9n4euv$t9m$1@slb6.atl.mindspring.net> <3B964C7A.BC04374E@icn.siemens.de> <9n5o9n$37a$1@slb7.atl.mindspring.net> <3%ul7.3362$9z1.440040@news6-win.server.ntlworld.com> <9n61dg$h3k$1@slb5.atl.mindspring.net> From: Ole-Hjalmar Kristensen Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii NNTP-Posting-Host: 194.143.59.98 X-Complaints-To: news-abuse@nextra.no NNTP-Posting-Date: Thu, 06 Sep 2001 08:48:30 MET DST Organization: Nextra Public Access X-Trace: readme.online.no 999758910 194.143.59.98 Date: 06 Sep 2001 08:48:30 +0200 Xref: archiver1.google.com comp.lang.ada:12782 Date: 2001-09-06T08:48:30+02:00 List-Id: "Brian Catlin" writes: > "chris.danx" wrote in message > news:3%ul7.3362$9z1.440040@news6-win.server.ntlworld.com... > > > > > > You should be able to "overload" a driver. What I mean ? Lets assume > > > > you have a simple grafic driver on bootup, then you load a "better" > > > > (more complex, higher resolution, 3D excelerator ...) one. If this one > > > > crashes, then it should simply be unloaded and the system should > > > > continue work with the (simple) default driver - instead of showing a > > > > "blue screen" ;-) > > > > > > My first reaction to this was "Not Possible". However, that isn't > > > entirely true; it is just *VERY VERY* difficult. > > > > Only in the "drivers in supervisor mode" model. > > > > > A driver runs in kernel mode, > > > > Why? Why not just have it in user mode? It makes more sense to have them > > in user mode, at least to me. They can only corrupt themselves then, etc. > > > > > and has access to system data structures. > > > > Why should it? In your model a driver can screw a system up good and > > proper, but if you put the driver in user mode then the associated problems > > go away. New ones do crop up, but there's ways and means to deal with them. > > This has been well studied and the reasons will show up in just about any > search of the relevant literature (in case my explanation does not make sense, > or are not complete enough for you). A driver typically runs in two contexts, > the context of the requesting process, because it needs to access the user's > buffers, and "system" context (strictly, arbitrary process context) where the > driver does not need access to the requesting process' address space. If a > driver is running in its own process, how can it gain efficient access to the > requesting process' buffers? Also, drivers spend most of their time running at It is possible (and has been done) to associate privileges with the memory segment you are currently executing in, not which process you are running in. In this way it is possible to get both speed and safety, by having special libraries with sufficient privileges. Kind of like the monitor/protected object idea, which lets you execute code within it without process switching. -- Kabelsalat ist gesund. Ole-Hj. Kristensen