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

Johnny Billquist bqt at softjar.se
Wed Jun 7 09:35:25 EDT 2023


On 2023-06-07 14:08, Simon Clubley wrote:
> On 2023-06-06, Scott Dorsey <kludge at panix.com> 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....
> 
> Microkernels are a far better solution for that and have the major
> advantage of conceptually being architecture neutral.

Pros and cons, as usual...

Slightly related, I could argue that RSX (and maybe to some extent VMS) 
are already slightly down the path of microkernels.

In RSX, the file system operations are done in a separate user level 
process, which is the F11ACP. And networking is done in yet another user 
level process, the NETACP. Task activation as well as rundown are yet 
again done by other user level processes (INS and TKTN).

This also means that in theory adding support for new file systems is 
just a question of writing another ACP and off you go. Unfortunately 
there are a few places where there are some assumptions in the system, 
making it not that easy to do absolutely everything in another file 
system. But for normal file accesses, it works just fine. (In RSX, the 
problem is that task checkpointing is done outside of the ACP, but to 
the file system.)

Which is way more separation than you'll find in any kind of Unix like 
system. But it's not as far as true microkernels go.

   Johnny




More information about the Info-vax mailing list