[Info-vax] New filesystem mentioned

[John Reagan]

On Thursday, May 16, 2019 at 2:10:36 PM UTC-4, Dave Froble wrote:
> On 5/16/2019 1:53 PM, John Reagan wrote:
> > On Thursday, May 16, 2019 at 1:43:48 PM UTC-4, Simon Clubley wrote:
> >> On 2019-05-16, Dave Froble <davef at tsoft-inc.com> wrote:
> >>> On 5/16/2019 10:04 AM, Bob Koehler wrote:
> >>>>
> >>>>      No, DLM is a separate part of the kernel, which is used by and
> >>>>      required by the XQP and such.
> >>>
> >>> Damn, that brings up another question.  Is the DLM part of the kernel?
> >>> I don't know the details of the implementation, but, I'd at least hope
> >>> it is not.  That would allow it to be used in any modular type of OS.
> >>
> >> It is a part of the kernel, but only in so far as there is no other place
> >> to put it in the current VMS design. I can't see anything about the VMS
> >> DLM which requires direct access to hardware for example.
> >>
> >> It provides services to the rest of the kernel (and to non-kernel
> >> applications). However, I see no reason why the DLM could not just be
> >> another task in a microkernel design (for example).
> >>
> >>> And before anyone mentions parts of the kernel might use the DLM, I'd
> >>> guess that might happen.  Doesn't mean anything used by the kernel is
> >>> part of the kernel.
> >>>
> >>
> >> In a VMS style monolithic design, it's all part of the kernel.
> >>
> >> This is because, on VMS, the DLM directly provides services to the rest
> >> of the kernel which means the kernel code needs direct and efficient
> >> access to the DLM.
> >>
> >> Think of it less about being part of the kernel and more about whether
> >> the DLM has a clean interface to the rest of the kernel (which would
> >> make it easier to use elsewhere).
> >>
> >> Going back to Linux, that's one of the advantages of the Linux module
> >> based architecture. It's all part of the kernel, but there are generally
> >> reasonably clean interfaces between the various parts of the kernel as
> >> a result.
> >>
> >> Simon.
> >>
> >> --
> >> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> >> Microsoft: Bringing you 1980s technology to a 21st century world
> >
> >
> >
> > SYSENQDEQ (and a few other modules) are in the LOCKING.EXE execlet.  One of many execlets loaded as part of the OS boot.
> >
> 
> Oh, no, this could degenerate into a discussion about "what is the VMS 
> kernel" and that could be a nasty knife fight.
> 
> I should shut up now, but let me ask, does getting loaded as part of the 
> OS boot indicate that all such modules are part of the kernel?
> 
> -- 
> David Froble                       Tel: 724-529-0450
> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA  15486

The code in LOCKING.EXE gets loaded into memory that is kernel-read/kernel-execute so once loaded, it looks like code from other execlets.  As each execlet is loaded, the entry points supplied by it are filled into the system-routine's transfer vector.  Each execlet has an init routine that is called by the execlet loader.  So is the execlet scheme just a packaging concept?  Or a limited form of code isolation concept?  I'll let others decide.  I'll go back to working on the compilers...

BTW, the latest bug was with BLISS-32 which has to make a in-memory argvector if the code uses the ARGPTR(), ACTUALARGUMENT(), or NULLARGUMENT() builtin.  On each of the platforms, we have to home the argument list from the "some in registers; some on the stack" to a "all-in-memory copy so it can be indexed dynamically".  The code we generated for "move the first 6 from registers to memory then copy 7 and above from their quadword stack slots to longword stack slots.  The code was off-by-one for reading the stack arguments.  Ooopsie.