[Info-vax] Why (conceptually) does executive mode code need unrestricted kernel mode access ?

[Simon Clubley]

On 2019-10-04, VAXman-  @SendSpamHere.ORG <VAXman- at SendSpamHere.ORG> wrote:
> In article <qn7d5t$tcf$1 at dont-email.me>, Simon Clubley <clubley at remove_me.eisner.decus.org-Earth.UFP> writes:
>>Why, at a conceptual level, does executive mode code need unrestricted
>>kernel mode access ?
>>
>>If kernel mode access is required, then why can't executive mode code go
>>through a normal system service to provide the additional functionality
>>like everyone else does ?
>>
>>For example, what does RMS actually _need_ direct unrestricted kernel mode
>>access for and why can't this be provided for by a normal system service ?
>
> It is. $CMKRNL.
>

No, sys$cmkrnl() is the system service that provides the direct
unrestricted kernel mode access from executive mode that I mention
above. This effectively turns VMS into, at best, a 3-mode operating system.

My question is why does executive mode code need direct unrestricted
access to kernel mode and why can't executive mode code have the same
more controlled access to kernel mode (via the normal system services)
that the rest of us use in our normal user mode programs ?

For example, when we call the lock manager or sys$qio() code from normal
user mode code, we end up running kernel mode code, but it is done via
a controlled system service interface that only allows specific operations
to be carried out in kernel mode.

Why does executive mode code require a direct and unrestricted access
to kernel mode ? What is so special about RMS that it requires direct
kernel mode access and why can't this kernel mode access be via some
kind of system service interface instead ?

Once again, there's no specific reason for the questions; it's just
something that occurred to me.

Thanks,

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.