Have spend a bit of time researching and thinking through the SSIO / RMS issues and it occurred to me that may be the SSIO is the right direction just not far enough.

What is critical is to ensure the RMS can access all files, and until VCC/XFC RMS did its own buffering. SSIO appears to be about access XFC bytes directly, and use XFC to coordinate the updating of the buffers and therefore the on-disk data. Good.

Lets assume the SSIO interface will be $QIO possibly using something like IO$M_RBYTE/IO$M_WBYTE. This would in effect be readp/writep (linux IO routines) on VMS. So lets externalize them as SYS$READP/SYS$WRITEP.

With the move to using XFC as the main buffering engine on VMS lets also remove all the RMS internal buffering. NB this does not remove SET RMS/... as those are still used in setting the FAB which passes that information to XFC. For those that don't know XFC uses the smallest MBC for a file as the buffer buffer size, and coordinates access to that buffer data across the cluster.

This would greatly simplify the current RMS code, and also by using $READP/WRITEP internally there is potential to reduce the RMS code base further, while also making RMS more Linux like.

Ahh the things we think of over the time of year...

gt

среда, 5 января 2022 г. в 03:02:05 UTC+3, tink...@gmail.com:

> Lets assume the SSIO interface will be $QIO possibly using something like IO$M_RBYTE/IO$M_WBYTE. This would in effect be readp/writep (linux IO routines) on VMS. So lets externalize them as SYS$READP/SYS$WRITEP.
>

Why do we need to assume? =)

int sys$ssio_readw(
unsigned short chan,
VOID_PQ buffer,
unsigned __int64 bufsiz,
IOSA_PL iosa,
RESTARTROUTINE64 ast,
VOID_PQ astprm);

int sys$ssio_writew(
unsigned short chan,
VOID_PQ buffer,
unsigned __int64 bufsiz,
IOSA_PL iosa,
RESTARTROUTINE64 ast,
VOID_PQ astprm);

On Saturday, 8 January 2022 at 4:38:42 am UTC+11, Vitaly Pustovetov wrote:

> Why do we need to assume? =)

I/we assume because that is the architecture of VMS, if you want to do an IO you use $QIO. What the internals do is up to the EXEC/KRNL code... From user mode I 'assume' $QIO. I also assume given it accesses XFC that is it cluster safe.

NB I missed typed, pread/pwrite are the 2 routines I am thinking about. (https://man7.org/linux/man-pages/man2/pread.2.html)

Even with the 'different' interface the still concept stands, we can use pread/pwrite (type calls) on top of XFC to replace all the RMS buffering, and yes we still need RMS record locking...

gt

> I/we assume because that is the architecture of VMS, if you want to do an IO you use $QIO. What the internals do is up to the EXEC/KRNL code... From user mode I 'assume' $QIO. I also assume given it accesses XFC that is it cluster safe.

We don't have to assume anything about the current interface of SSIO. Because it is already define.
p.s. About cluster support - "SSIO V1 has minimum cluster support".

On Sunday, 9 January 2022 at 4:12:43 am UTC+11, Vitaly Pustovetov wrote:
Hi Vitaly

> We don't have to assume anything about the current interface of SSIO. Because it is already define.
It is not in any 'released' documentation, possibly part of FT and therefore subject to change...

If you look at the parameters they are almost $QIO so why not change it so they are.

One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue. NB in this case the correct solution was FIX CRTL to use RMS correctly.

My point is lets use this change to benefit lots of requirements for VMS, not just Postgresql. Part of that would be to code pread/pwrite in CRTL to use this interface, and have the byte update XFC/SSIO API visible to all code that uses ACP/XPQ.

> p.s. About cluster support - "SSIO V1 has minimum cluster support".
Yup, it does not define what 'minimum cluster support' is. For more minimum cluster support means it supports cluster, end of, i.e. it either supports cluster, which if it uses XFC it must, or it is some other interface maybe hacking XFC which we don't want.

XFC by it's very nature coordinates the updating of 'buffers' (MBC's) for all files in the cluster across all systems in that cluster. If it does not work that way then a lot of things will break. If it does work that way, and we have a reasonable expectation that it does, then implicitly SSIO will work across a cluster subject to the application code coordinating the access to the data to avoid those issues that are outside XFC's control, aka serializing data access probably using LCK$...

Back to my main point, RMS buffer can go. We can now use XFC to do the local/global buffering, NB XFC may need some tweaking so it will use bucket size, and number of buffers as set by $ SET RMS/BUFF... which it sort of does now anyway.

gt

On 1/8/2022 7:07 PM, Greg Tinkler wrote:
> On Sunday, 9 January 2022 at 4:12:43 am UTC+11, Vitaly Pustovetov
> wrote: Hi Vitaly
>> We don't have to assume anything about the current interface of
>> SSIO. Because it is already define.
> It is not in any 'released' documentation, possibly part of FT and
> therefore subject to change...
>
> If you look at the parameters they are almost $QIO so why not change
> it so they are.
>
> One if the things that a lot of users of VMS have liked years is the
> focus on quality engineering looking at the whole OpenVMS
> environment, and not a knee jerk response to some particular issue.
> NB in this case the correct solution was FIX CRTL to use RMS
> correctly.

Somehow I doubt that.

Arne

On Sunday, 9 January 2022 at 11:28:32 am UTC+11, Arne Vajhøj wrote:
Hi Arne

> Somehow I doubt that.

What do you doubt?
I wrote some test code that 'fixed' the issue and emulated what CRTL should do. Only took a few days, and it worked as expected.

Or is there something else you doubt? Maybe you doubt VMS engineering group tried hard to make a quality product, I doubt that as I also found them to be very professional and focused on quality. But that was back in the day, 30 years ago.

So doubts? Would you like to expand that.

gt

On 1/8/2022 7:35 PM, Greg Tinkler wrote:
> On Sunday, 9 January 2022 at 11:28:32 am UTC+11, Arne Vajhøj wrote:
>> Somehow I doubt that.
>
> What do you doubt?

That it can be done as a CRTL fix.

> I wrote some test code that 'fixed' the issue and emulated what CRTL should do. Only took a few days, and it worked as expected.

In that case I suggest you wrap up all the code with the
read/write/whatever prefixed with GT$ or whatever and release
it, then everybody should be able to build and run PostgreSQL
safely on VMS just by doing a few defines - on all VMS
including HP VMS and VMS VAX etc..

Arne

On Sunday, 9 January 2022 at 12:09:36 pm UTC+11, Arne Vajhøj wrote:
yes not maybe, in case you have not noticed OpenVMS is a commercial operation. It would be great if VSI published what they did to make clang/llvm work on Linux to build bits for VMS...

What I will show is to key bit to solving the problem.
fdptr->fab->fab$b_rfm = FAB$C_UDF;
fdptr->fab->fab$v_esc = 1;
fdptr->fab->fab$l_ctx = RME$C_SETRFM;
sts = sys$modify (fdptr->fab);

And no I don't feel like having to explain it, you ether understand or don't.

gt

On Saturday, January 8, 2022 at 8:38:32 PM UTC-5, tink...@gmail.com wrote:
> On Sunday, 9 January 2022 at 12:09:36 pm UTC+11, Arne Vajhøj wrote:
> It would be great if VSI published what they did to make clang/llvm work on Linux to build bits for VMS...
>
I've discussed this before but we'll provide the code. I still want to push the LLVM code back to the LLVM git repo.

Essentially, the LLVM changes are
- add an argcount
- add some extra ELF .note sections for module name, etc. but the linker will be ok without it
- add some extra code to make sure we always go through the GOT for static data (like the medium model but not quite) since code will be in 64-bit space but static data is always 32-bit. If you like with /SEGMENT=CODE=P0, you don't need it
- add code to specify .personality routines as specified by the frontend. LLVM is still biased to thinking that .personality routines are all about C++ try/catch.
- add code to deal with more complex LTCEs for "symbol - symbol" relocations

You can go watch my LLVM 5-minute lightning talk from a few years back. Head over to the LLVM channel on YouTube and search for my name. You'll find both talks I've presented.

For clang, that's still a work-in-progress, but RTL prefixing, dual-size pointers (leveraging the existing support in clang), pragma nomember_alignment (almost like pack), headers from TLB files, etc.

On Saturday, January 8, 2022 at 7:07:58 PM UTC-5, tink...@gmail.com wrote:

> If you look at the parameters they are almost $QIO so why not change it so they are.

QIO is a generic interface, this a specific one.
It's called progress without being disruptive, still giving a familiar touch and feel.
Switch to all 64 bit, ditch the crud.
IO$_READVBLK orred with modifier bits? Yuck!
Almost too bad they kept the 'channel' instead of a generic (more) opaque 'handle'.
Almost because but I do love my SDA> SHOW PROC/CHAN and such.

> One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue.

Steam IO a knee-jerk reaction? Ha! It's been looked at, worked on for 20+ years.

> NB in this case the correct solution was FIX CRTL to use RMS correctly.

Nonsense. The C-RTL folks didn't live/work in a vacuum. They know/knew how to use RMS, they know about the FAB$C_UDF hackery.
They know (and implemented) how NOT to use (buffered) RMS and switch to SYS$READ/SYS$WRITE to avoid excessive going in an out of EXEC mode with all the probing for simple actions.

> > p.s. About cluster support - "SSIO V1 has minimum cluster support".
> Yup, it does not define what 'minimum cluster support' is. For more minimum cluster support means it supports cluster, end of, i.e. it either supports cluster,
> which if it uses XFC it must, or it is some other interface maybe hacking XFC which we don't want.

You mistakenly believe that XFC usefully supports clusters. It doesn't. It merely coexists peacefully.
All the XFC caches for a file on one node are invalidated when a change, any change, anywhere is made for that file on an other node.

> XFC by it's very nature coordinates the updating of 'buffers' (MBC's) for all files in the cluster across all systems in that cluster.

Noop.

> If it does not work that way then a lot of things will break.

Correct. The XFC knows just enough to walk away before it breaks.

> If it does work that way, and we have a reasonable expectation that it does,

Noop.

> Back to my main point, RMS buffer can go.

Now there you are correct.

The whole goal of stream IO should be to get rid of protected process buffers and use shared system buffers like Linux does.

> We can now use XFC to do the local/global buffering, NB XFC may need some tweaking so it will use bucket size, and number of buffers as set by $ SET RMS/BUFF... which it sort of does now anyway.

I disagree. Let RMS keep doing the global buffers, relative files, indexed files, bucket size
Just solve the shared sequential file problems.

fwiw, I don't see how the XFC 'sort of does' take MBC, MBF, BKS into consideration. It doesn't. It just divides a file up in 8KB (or was it 16) cache lines with zero consideration for actual usage. In fact the default for indexed and relative file causes maximum overhead due to the prologue block(s) in those files as well as the typically 'odd' cluster sizes.
Even if you make the bucket size a nice multipel of fraction of a cache line, you'll start off with the odd bucket and there will need an extra cache line all the time.
I did extensive experiments with this back in the day (Mark Hopkins!) .
If you tweak an Indexed file just so - over and beyond normal tweaking - you can get a few percent improvement - reducing CPU and IO.
(make cluster size a multiple of 16, make bucket size a multiple or divisible fraction of 16, make the data NOT be in AREA 0 which has the prologue)

Cheers,
Hein

On Sunday, 9 January 2022 at 2:29:39 pm UTC+11, xyzz...@gmail.com wrote:
thanks John, it is one hell of a task you have to get all those compilers to work...

Hi Hein

yup maybe are correct about XFC, I though I had read some thing somewhere (by Keith Parris, talking about using hash lookups on the buffers and some tweaks for the locks, must have been dreaming) ... Sad, I had hoped after all the learnings from VCC and earlier XFC things may have improved.

So given the state of play with XFC, and it does not work as expected
- fix XFC so it works, until it does use RMS buffering
- fix CRTL so it works correctly, it is always to have the correct data than slow data
- longer term, once XFC is working well, move RMS to use it for buffering
- don't use SSIO until XFC is fixed

Yes $QIO is a generic interface, that is exactly why I think it should be used. If this is a 'special' case for Postgresql, then maybe call it PQL$special_io(), and only have it documented for that particular use. Otherwise it will become general usage, and therefore should be a generic API.

воскресенье, 9 января 2022 г. в 03:07:58 UTC+3, tink....@gmail.com:
> If you look at the parameters they are almost $QIO so why not change it so they are.
For what? We have a new 64-bit system for working with "regular" files. Why access it through $QIO and not through convenient functions?
> NB in this case the correct solution was FIX CRTL to use RMS correctly.
The authors of RMS have invented and made SSIO. Do you think they were wrong and we need to correct the CRTL? I'm not sure if your solution will work and it will probably be slower than SSIO.
> My point is lets use this change to benefit lots of requirements for VMS, not just Postgresql. Part of that would be to code pread/pwrite in CRTL to use this >interface, and have the byte update XFC/SSIO API visible to all code that uses ACP/XPQ.
read/write/pread/pwrite/readv/writev are SSIO ready since 2005. ;)

On 1/8/2022 8:38 PM, Greg Tinkler wrote:
> On Sunday, 9 January 2022 at 12:09:36 pm UTC+11, Arne Vajhøj wrote:
> yes not maybe, in case you have not noticed OpenVMS is a commercial operation.

That does not prevent you from publishing C code that
solve the problem on all VMS versions.

> What I will show is to key bit to solving the problem.
> fdptr->fab->fab$b_rfm = FAB$C_UDF;
> fdptr->fab->fab$v_esc = 1;
> fdptr->fab->fab$l_ctx = RME$C_SETRFM;
> sts = sys$modify (fdptr->fab);
>
> And no I don't feel like having to explain it, you ether understand or don't.

That is the C equivalent of:

$ SET FILE/ATTR=RFM:UDF

And if you think that is the solution to the SSIO problem, then
I am changing my opinion from "Somehow I doubt that" to
"I totally do not believe that".

Arne

Hi Vitaly

VMS has it's file systems, and it assumes the use of RMS to access files. We don't need to reinvent the wheel, just use it better.

no the authors of RMS did not invent SSIO, RMS was written for RSX/RSTS way back when...
SSIO was developed by developers with a *nix background.

Also after 17 years and it still not working don't you think it is time to move on, and just fix CRTL. NB I have also stated that RMS should be fixed but until then the work around I have suggested to a good fit.

Arne
Yup it 'pretends' that the file is UDF, but does not change the file itself.. This allow the access to change on the fly to UDF and back, which then allows all the other RMS functions to work as expected.

Does it work, yes it does, been there, got the tee-shirt. Re the code, since I am talking about replacing CRTL components it should be done within the auspices of CRTL, so FD/FCB etc all correctly managed. If VSI want to send me all the CRTL relating the files then maybe... But I don't think that is practical, do you?

Anyway, like most IT people I have work I get paid to do, including looking after VMS systems.

gt

On 1/9/2022 6:49 PM, Greg Tinkler wrote:
> Arne Yup it 'pretends' that the file is UDF, but does not change the
> file itself. This allow the access to change on the fly to UDF and
> back, which then allows all the other RMS functions to work as
> expected.
>
> Does it work, yes it does, been there, got the tee-shirt. Re the
> code, since I am talking about replacing CRTL components it should be
> done within the auspices of CRTL, so FD/FCB etc all correctly
> managed. If VSI want to send me all the CRTL relating the files then
> maybe... But I don't think that is practical, do you?

There is no need for all of that. It can be done other ways.
Most simple would be an acc callback in open to change it
and a revert routine using saved info.

But I am amazed that someone believe that such 20 lines would
solve a problem VMS engineering has spent a decade or more
on.

Arne

Arne

frankly I am not surprised that the offshore VMS group could fix it, I am surprised the the back in the 80/90's the CRTL folk did not talk with the RMS group and have a good solution in place to start with. But then C IO was a very low priority, you either did RMS or your own $QIO. Now with open source it is a very different ball game.

SSIO is not and was never a well designed solution. It looks more like a *nix persons view of how VMS should work.

Once XFC can be properly used for buffer sharing across the cluster, and RMS can use it, then maybe, but why not then just use RMS. The main question re XFC is the focus disk io buffering or file caching. If it is disk IO then it should probably use the device's 'cluster size' as the buffer size, if it is file buffering then it should be MBC/Bucket size. Using some 'fixed' value that does not match either of these will/does cause issues...

The SYS$MODIFY's function is what you just described, after an open, get RMS to pretend that the file is of a different format. And no it is not just 20 lines, that was the few line to help those that don't understand VMS/RMS what is possible. Careful code design would allow the initial open to use UDF so you don't need to do it each IO.

"There is no need for all of that. It can be done other ways."
Well if that is the case then please put your code up... and clearly you don't think SSIO is a good solution either. 8-))

gt

And sorry if have been a bit blunt, a couple of COVID19 scares...

gt

On 2022-01-08, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:
> On Saturday, January 8, 2022 at 7:07:58 PM UTC-5, tink...@gmail.com wrote:
>
>> One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue.
>
> Steam IO a knee-jerk reaction? Ha! It's been looked at, worked on for 20+ years.
>

There are some people who are just unwilling to accept that just because
that's how something was done 30 years ago, it doesn't mean that's how it
should be done these days in light of general advancements in technology.

>> NB in this case the correct solution was FIX CRTL to use RMS correctly.
>
> Nonsense. The C-RTL folks didn't live/work in a vacuum. They know/knew how to use RMS, they know about the FAB$C_UDF hackery.
> They know (and implemented) how NOT to use (buffered) RMS and switch to SYS$READ/SYS$WRITE to avoid excessive going in an out of EXEC mode with all the probing for simple actions.
>

Switching between Executive and User modes is not free, especially when
you are emulating Executive mode. :-)

Simon.

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

On 1/9/2022 9:57 PM, Greg Tinkler wrote:
> frankly I am not surprised that the offshore VMS group could fix it,
> I am surprised the the back in the 80/90's the CRTL folk did not talk
> with the RMS group and have a good solution in place to start with.
> But then C IO was a very low priority, you either did RMS or your own
> $QIO. Now with open source it is a very different ball game.
>
> SSIO is not and was never a well designed solution. It looks more
> like a *nix persons view of how VMS should work.

> The SYS$MODIFY's function is what you just described, after an open,
> get RMS to pretend that the file is of a different format. And no it
> is not just 20 lines, that was the few line to help those that don't
> understand VMS/RMS what is possible. Careful code design would allow
> the initial open to use UDF so you don't need to do it each IO.
>
> "There is no need for all of that. It can be done other ways." Well
> if that is the case then please put your code up... and clearly you
> don't think SSIO is a good solution either. 8-))

I think SSIO is the only solution.

I don't believe the UDF hack is the solution.

But the UDF hack is not difficult to write.

Little bit more than 20 lines. With single reset call
for multiple files I ended up with a whooping 62 lines
of code.

$ type hack.c
#include <stdio.h>

#include <starlet.h>
#include <lib$routines.h>
#include <rms.h>
#include <rmedef.h>

static void set_rfm(struct FAB *fab, long int rfm)
{ long int stat;
fab->fab$l_fop |= FAB$M_ESC;
fab->fab$l_ctx |= RME$C_SETRFM;
fab->fab$b_rfm = rfm;
stat = sys$modify(fab,0,0);
if(stat & 1 == 0) lib$signal(stat);
}

static long int set_rfm_ext(struct FAB *fab, long int rfm)
{ long int stat;
long int oldrfm;
stat = sys$open(fab,0,0);
if(stat & 1 == 0) lib$signal(stat);
oldrfm = fab->fab$b_rfm;
set_rfm(fab, rfm);
stat = sys$close(fab,0,0);
if(stat & 1 == 0) lib$signal(stat);
return oldrfm;
}

#define MAX_FAB 100
static long int savrfm[MAX_FAB];
static struct FAB *savfab[MAX_FAB] = { NULL };

int hack_udfify_callback(int *first_arg, struct FAB *fab, struct RAB *rab)
{ int i;
long int oldrfm;
oldrfm = set_rfm_ext(fab, FAB$C_UDF);
for(i = 0; i < MAX_FAB; i++)
{
if(savfab[i] == NULL)
{
savrfm[i] = oldrfm;
savfab[i] = fab;
break;
}
}
return 0;
}

void hack_reset()
{ int i;
for(i = 0; i < MAX_FAB; i++)
{
if(savfab[i] != NULL)
{
set_rfm(savfab[i], savrfm[i]);
}
}
}

It works as expected.

$ type demo.c
#include <stdio.h>
#include <stdlib.h>

#include "hack.h"

void test1(char *fnm)
{ char cmd[1024];
sprintf(cmd, "write sys$output f$file_attributes(\"%s\",\"RFM\")", fnm);
system(cmd);
}

void test()
{ test1("z.1");
test1("z.2");
test1("z.3");
}

int main()
{ FILE *fp1, *fp2, *fp3;
test();
printf("Open files (2 with udfify callback and 1 without)\n");
fp1 = fopen("z.1", "r+", "shr=get", "acc", hack_udfify_callback, NULL);
fp2 = fopen("z.2", "r+", "shr=get", "acc", hack_udfify_callback, NULL);
fp3 = fopen("z.3", "r+", "shr=get");
test();
printf("Reset and close files\n");
hack_reset();
fclose(fp1);
fclose(fp2);
fclose(fp3);
test();
return 0;
}

$ cc demo
$ cc hack
$ link demo+hack
$ run demo
VAR
VAR
VAR
Open files (2 with udfify callback and 1 without)
UDF
UDF
VAR
Reset and close files
VAR
VAR
VAR

I just don't think it is useful for anything.

Arne

Hi Arne

thank for doing that. What it does is fix the issue SSIO was built to solve, and it is cluster safe, i.e. the 2 programs accessing the same file can update close data without destroying each other updates.

What I was taught re coding
- make it work
- make secure
- make it fast
Always in that order.

The coding needed to change CRTL is still a lot more than 62 lines, but the end results can be back ported to earlier versions of VMS, including VAX. Which then raises other question with CRTL and fiel support for open source applications, e.g. PHP. PHP has a habit of doing putw() so support wide characters, but CRTL does not seem to cache these until a 'lf' (\n) is received. This is a performance issue, so just an annoyance. I'm sure there is a lot of CRTL related issues for open source tat need to be worked through.

Simon
re "how something was done 30 years ago", you are correct, some people like you seem to believe 2 mode OS's are the go, not 4 mode. The research was done 50 years ago and the outcome was 4 mode. And which advancements? Things have got bigger and faster but the underlying architecture is still based on work done in WWII which is before I was born.

Yes there is a performance cost, there always is for security. NB most *nix now have lots of code in kernel just checking for possible hacks...

gt

In article <srhv8g$td8$5@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-01-08, Hein RMS van den Heuvel <heinvandenheuvel@gmail.com> wrote:
>> On Saturday, January 8, 2022 at 7:07:58 PM UTC-5, tink...@gmail.com wrote:
>>
>>> One if the things that a lot of users of VMS have liked years is the focus on quality engineering looking at the whole OpenVMS environment, and not a knee jerk response to some particular issue.
>>
>> Steam IO a knee-jerk reaction? Ha! It's been looked at, worked on for 20+ years.
>>
>
>There are some people who are just unwilling to accept that just because
>that's how something was done 30 years ago, it doesn't mean that's how it
>should be done these days in light of general advancements in technology.
>
>>> NB in this case the correct solution was FIX CRTL to use RMS correctly.
>>
>> Nonsense. The C-RTL folks didn't live/work in a vacuum. They know/knew how to use RMS, they know about the FAB$C_UDF hackery.
>> They know (and implemented) how NOT to use (buffered) RMS and switch to SYS$READ/SYS$WRITE to avoid excessive going in an out of EXEC mode with all the probing for simple actions.
>>
>
>Switching between Executive and User modes is not free, especially when
>you are emulating Executive mode. :-)

Huh?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-01-11, VAXman- @SendSpamHere.ORG <VAXman-@SendSpamHere.ORG> wrote:
> In article <srhv8g$td8$5@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>>Switching between Executive and User modes is not free, especially when
>>you are emulating Executive mode. :-)
>
> Huh?
>

Mode transitions are not free Brian, especially when you are emulating
Executive mode, as will be the case on x86-64 VMS.

However, the PCID stuff will help enormously with that thankfully.

Simon.

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

On 2022-01-10, Greg Tinkler <tinklerg@gmail.com> wrote:
>
> Simon
> re "how something was done 30 years ago", you are correct, some people
> like you seem to believe 2 mode OS's are the go, not 4 mode. The research
> was done 50 years ago and the outcome was 4 mode. And which advancements?
> Things have got bigger and faster but the underlying architecture is still
> based on work done in WWII which is before I was born.
>

From a security point of view, VMS is a 2-mode operating system, not a
4-mode operating system. Once you are in one of the inner modes, you
can get to any of the other two inner modes without needing any additional
account privileges.

And BTW, the most secure design these days is the microkernel design
because that design isolates components that would normally be in a
monolithic kernel from each other and also gives them restricted
access rights and privileges. Those designs run just fine on a 2-mode
hardware architecture.

> Yes there is a performance cost, there always is for security. NB most
> *nix now have lots of code in kernel just checking for possible hacks...
>

Having all the ASLR/KASLR/mandatory access control security in Linux is
a very good thing and it should be present in VMS as well.

The fact you seem to think this is a bad thing tells me you really
are living in the past.

Simon.

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