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,LOTS_OF_MONEY
	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-07 04:04:51 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!feeder.qis.net!washdc3-snh1.gtei.net!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: Ada OS Kernel features
Date: 7 Sep 2001 06:04:48 -0500
Organization: LJK Software
Message-ID: <Y3d07tajIARi@eisner.encompasserve.org>
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>
 <wjwKHdGfRR9P@eisner.encompasserve.org>
 <UWOl7.11352$592.628767@news2-win.server.ntlworld.com>
 <d8$8gnF$GFEk@eisner.encompasserve.org>
 <pQSl7.12306$592.1131328@news2-win.server.ntlworld.com>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 999860691 21901 192.135.80.34 (7 Sep 2001
 11:04:51 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Fri, 7 Sep 2001 11:04:51 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:12880
Date: 2001-09-07T06:04:48-05:00
List-Id: <comp.lang.ada>

In article <pQSl7.12306$592.1131328@news2-win.server.ntlworld.com>, "chris.danx" <chris.danx@ntlworld.com> writes:
> 
> "Larry Kilgallen" <Kilgallen@SpamCop.net> wrote in message
> news:d8$8gnF$GFEk@eisner.encompasserve.org...
>> In article <UWOl7.11352$592.628767@news2-win.server.ntlworld.com>,
> "chris.danx" <chris.danx@ntlworld.com> writes:
>> >
>> >> > I really don't get why a driver must have access to system structures
> or
>> >> > atleast those in kernel space, can you explain this?
>> >>
>> >> A driver has access to raw hardware.  Therefore it necessarily has
>> >> access to the system -- it could rewrite the copy of the OS on disk
>> >> if it chose.
>> >
>> > Perhaps, but that's a problem that could be solved, in part, by
> restricting
>> > what the drivers allowed to access.  Video drivers have no business
> using
>> > the disk, so their access to disk access ports should be denied.
> Similar
>> > schemes should be used when appropriate.  It should not be possible for
> a
>> > driver to access things willy nilly.
>>
>> My impression was that the goal was to use existing hardware that is
>> widely available.
> 
> Yes. why? Do you think that won't work across all hardware?

Because access to IO pages must be protected by access mode,
and hardware granularity does not allow protecting the disk
device from the video driver.