[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