[Info-vax] Intel proposal to simplify x86-64

[Dan Cross]

In article <u5pi81$v2q$1 at news.misty.com>,
Johnny Billquist  <bqt at softjar.se> wrote:
>On 2023-06-07 01:07, Scott Dorsey wrote:
>> Johnny Billquist  <bqt at softjar.se> wrote:
>>> On 2023-06-06 19:55, Scott Dorsey wrote:
>>>> John Dallman <jgd at cix.co.uk> wrote:
>>>>> In article <63a25e5a-2001-451b-b8a7-d6d9e74b02f9n at googlegroups.com>,
>>>>> xyzzy1959 at gmail.com (John Reagan) wrote:
>>>>>
>>>>>> Other than an impact on the boot loader due to the change in
>>>>>> startup mode, it has essentially no impact on OpenVMS
>>>>>>
>>>>>> OpenVMS does not use ring 1 or 2.  The 64-bit mode PTEs don't
>>>>>> include support for ring 1 or 2 today, just ring 0 and 3.
>>>>>
>>>>> Thanks, glad to hear it.
>>>>
>>>> I'm not necessarily glad to hear it because I like the idea of keeping
>>>> device drivers in a different ring than user processes or kernel....
>>>
>>> Hmm. Am I misremembering something? As far as I can recall, device
>>> drivers in VMS (at least on VAX) are running in kernel mode. RMS in EXEC
>>> and DCL in SUPER (or was it the other way around?).
>> 
>> Yes.  It's a shame.  When the new i386 rings came out I was thinking
>> "Wow, we could do Honeywell-style stuff and it's not a mess like the
>> 286 but... then nobody ever did.
>
>Well. If you want full isolation between different parts of the kernel, 
>going fully microkernel and message passing and all that, it's perfectly 
>doable on pretty much any hardware. It's just that in general, whenever 
>it has been done, performance always suffer. Which is why pretty much 
>noone is doing it. And it's not because of issues in the hardware that 
>it suffers. It's just that you can't avoid a lot more overhead when 
>doing things this way. A lot of data copying first and foremost.
>
>I guess Honeywell did, but can't say they were overly successful. MACH 
>also did, but that part seems to not live on anywhere.

Hmm.  The Honeywell systems, perhaps exemplified by Multics,
were rather the inverse of a microkernel: they used a single
shared store for _everything_; sharing was at the granularity of
a segment, with direct call-gating between segments at different
protection rings.

	- Dan C.