In article <srk23s$nbg$2@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>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.

Do they over-emphasis pedantry in the British schools or did you just have
a rough potty training period?

--
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, John Dallman <jgd@cix.co.uk> wrote:
> In article <srk2oj$nbg$3@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> 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.
>
> VMS C 7.4-1, which is current for Alpha and Itanium, also appears to lack
> any form of stack canary system.
>

There was a discussion about this at the time of the DCL CVE and
it turned out there was nothing like this in the DEC compilers.

However, at that time, John was planning to add this to the LLVM
based compilers at some point. I don't know the current status of that.

> Is there a way to mark stacks as non-executable?
>

Do any of the DEC compilers generate code that executes on the stack
at runtime ?

BTW, am I the only one who thinks it's a pity that stacks don't grow
upwards towards higher addresses instead of downwards towards lower
addresses, and with a guard page at the top of the space allocated to
the stack ?

After all, when using virtual memory, the space allocated to the stack
isn't actually allocated from memory until its needed.

Simon.

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

On 1/11/2022 1:43 PM, Simon Clubley wrote:
> BTW, am I the only one who thinks it's a pity that stacks don't grow
> upwards towards higher addresses instead of downwards towards lower
> addresses, and with a guard page at the top of the space allocated to
> the stack ?
>
> After all, when using virtual memory, the space allocated to the stack
> isn't actually allocated from memory until its needed.

I think:

K stack
E stack
S stack
U stack
unused
U heap

is more logical than:

stop
unused
U stack
S stack
E stack
K stack
unused
U heap

:-)

Arne

On 2022-01-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
> On 1/11/2022 1:43 PM, Simon Clubley wrote:
>> BTW, am I the only one who thinks it's a pity that stacks don't grow
>> upwards towards higher addresses instead of downwards towards lower
>> addresses, and with a guard page at the top of the space allocated to
>> the stack ?
>>
>> After all, when using virtual memory, the space allocated to the stack
>> isn't actually allocated from memory until its needed.
>
> I think:
>
> K stack
> E stack
> S stack
> U stack
> unused
> U heap
>
> is more logical than:
>
> stop
> unused
> U stack
> S stack
> E stack
> K stack
> unused
> U heap
>
>:-)
>
> Arne
>

You appear to be thinking in the above diagram that they are all part of
one big stack.

That's not correct because the multiple stacks outside of user space
all have their own allocated address ranges with page protections to match.

Even if they were contiguous, one stack couldn't grow into another stack
and there's no reason why the other non-user stacks couldn't grow upwards
within their own allocated address ranges either.

Simon.

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

On 1/11/2022 2:08 PM, Simon Clubley wrote:
> On 2022-01-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 1/11/2022 1:43 PM, Simon Clubley wrote:
>>> BTW, am I the only one who thinks it's a pity that stacks don't grow
>>> upwards towards higher addresses instead of downwards towards lower
>>> addresses, and with a guard page at the top of the space allocated to
>>> the stack ?
>>>
>>> After all, when using virtual memory, the space allocated to the stack
>>> isn't actually allocated from memory until its needed.
>>
>> I think:
>>
>> K stack
>> E stack
>> S stack
>> U stack
>> unused
>> U heap
>>
>> is more logical than:
>>
>> stop
>> unused
>> U stack
>> S stack
>> E stack
>> K stack
>> unused
>> U heap
>>
>> :-)
>
> You appear to be thinking in the above diagram that they are all part of
> one big stack.

No. 4 items called stack means 4 stacks.

But they are all in P1 space - together with a lot of other stuff
not shown - including DCL.

> That's not correct because the multiple stacks outside of user space
> all have their own allocated address ranges with page protections to match.

KES stacks do have fixed size - similar to MT U stacks.

But they are still in P1 space.

> Even if they were contiguous, one stack couldn't grow into another stack
> and there's no reason why the other non-user stacks couldn't grow upwards
> within their own allocated address ranges either.

The KES stacks could be filled up from the bottom instead of from the top.

But I still think it would look weird to have P1 filled up from 0x4000000.

Arne

On 1/11/2022 2:25 PM, Arne Vajhøj wrote:
> On 1/11/2022 2:08 PM, Simon Clubley wrote:
>> On 2022-01-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> On 1/11/2022 1:43 PM, Simon Clubley wrote:
>>>> BTW, am I the only one who thinks it's a pity that stacks don't grow
>>>> upwards towards higher addresses instead of downwards towards lower
>>>> addresses, and with a guard page at the top of the space allocated to
>>>> the stack ?
>>>>
>>>> After all, when using virtual memory, the space allocated to the stack
>>>> isn't actually allocated from memory until its needed.
>>>
>>> I think:
>>>
>>> K stack
>>> E stack
>>> S stack
>>> U stack
>>> unused
>>> U heap
>>>
>>> is more logical than:
>>>
>>> stop
>>> unused
>>> U stack
>>> S stack
>>> E stack
>>> K stack
>>> unused
>>> U heap
>>>
>>> :-)
>>
>> You appear to be thinking in the above diagram that they are all part of
>> one big stack.
>
> No. 4 items called stack means 4 stacks.
>
> But they are all in P1 space - together with a lot of other stuff
> not shown - including DCL.
>
>> That's not correct because the multiple stacks outside of user space
>> all have their own allocated address ranges with page protections to
>> match.
>
> KES stacks do have fixed size - similar to MT U stacks.
>
> But they are still in P1 space.
>
>> Even if they were contiguous, one stack couldn't grow into another stack
>> and there's no reason why the other non-user stacks couldn't grow upwards
>> within their own allocated address ranges either.
>
> The KES stacks could be filled up from the bottom instead of from the top.
>
> But I still think it would look weird to have P1 filled up from 0x4000000.

And there is the practical point of growing from the ends allowing the
division between P0 and P1 to adjust as needed.

Arne

On 1/10/2022 6:11 PM, Greg Tinkler wrote:
> 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.

No. It does not fix it.

It is quite trivial to create a program based on the presentation
from VMS engineering and show that the problem is seen with
normal setup, files created as UDF and files temporarily made UDF.

Arne

Hi Arne

You seem quite emphatic that is does not work, well
[12:37:29,12:37:00]
[12:37:31,12:37:32]
[12:37:33,12:37:34]
[12:37:35,12:37:36]
[12:37:37,12:37:38]
[12:37:39,12:37:40]
[12:37:41,12:37:42]

This may not seem much but the first timestamp is from 1 process and the other from another process.
If you use CRTL, SAME CODE it does not work and shows the problem described.
[12:37:53,12:37:48]
[12:41:09,12:37:48]
[12:41:11,12:37:48]
[12:41:13,12:37:48]

As you can see the second process details are not being updated, even though this is what is being updated.
[12:37:48,]
[12:41:19,]
[12:41:21,]
[12:41:23,]
[12:41:25,]

However using my approach, and doing the correct coding, you get the results above.

IT BL**DLY WORKS!!!

If VSI want to approach me about the code, that is fine, but here is a short code snippet to help you understand it
TSS$SETRFA (fdptr->rab, offset);
fdptr->rab->rab$b_rac = RAB$C_RFA;
// get the data so RMS is happy, nb may only needs some at the start of the data
sts = sys$get (fdptr->rab);
fdptr->rab->rab$l_rbf = (void *) buf;
fdptr->rab->rab$w_rsz = buflen;
sts = sys$update (fdptr->rab);

Oh and the test code
/*
* File: rms_unixio_test1.c
* Author: greg
* copyright 2021, 2022 TS Solutions Pty Ltd
*
*/
#include <errno.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>
#include <time.h>

//#define TSS$UNIXIO_ENABLE
#include "rms_unixio.h"

#define MAX_REC_LEN 40

/*
*
*/
int main (int argc, char** argv)
{ char fn[] = "rms_unixio.bin";
char *recbuff1, *recbuff2;
time_t rawtime;
struct tm *tm0;
char inbuf[50], ts[20];
int i, fd, sts, rno;
long rec_len1, rec_len2;
long long rec_offset1, rec_offset2;
char *sptr;

recbuff1 = (char *)malloc (MAX_REC_LEN);
recbuff2 = (char *)malloc (MAX_REC_LEN);
rec_len1=20;
rec_len2=20;

fd = open(fn, O_RDWR, 0777); /*,"ctx=bin","rfm=udf"); */
if (fd < 0)
{
perror("*** Unable to open file");
exit (0);
}

rno = 1;
printf ("record number, 0 to finish: ");
sptr = fgets (inbuf, sizeof (inbuf), stdin);
rno = atoi (inbuf);
if(rno==0) exit(0);
rec_offset1=(rno-1) * rec_len1;
rec_offset2=(rno) * rec_len2;

while (rno > 0)
{
/* get record number to change */
if (rno > 0)
{
sts = pread(fd, recbuff1, rec_len1, rec_offset1);
sts = pread (fd, recbuff2, rec_len2, rec_offset2);
/* show what we got */
printf ("[%.8s,%.8s]\n", recbuff1, recbuff2);
/* get current time */
time (&rawtime);
tm0 = localtime (&rawtime);
strftime (ts, sizeof (ts), "%H:%M:%S", tm0);
/* format output */
snprintf (recbuff1, 9, "%.8s\0", ts);
sts = pwrite (fd, recbuff1, rec_len1, rec_offset1);
sleep(2); /* sleep for 2 seconds */
}
}
/* don't close until requested */
sts = close (fd);
return (EXIT_SUCCESS);
}

So drop SSIO, fix CRTL, and yes someone after 20 years has been able to easily and quickly solve the problem.

gt

On 2022-01-11, John Dallman <jgd@cix.co.uk> wrote:
> In article <srkj4r$m7g$2@dont-email.me>,
> clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
>
>> However, at that time, John was planning to add this to the LLVM
>> based compilers at some point. I don't know the current status of
>> that.
>
> Most of that will come free with the LLVM compilers. The thing that will
> probably be different is the error generation when checks are failed. On
> OSes where I've used stack buffer overflow protection, failing a check
> generally terminates the process.
>

In addition to the usual suspects, John was also talking at the time
about seeing if this could be added into the Macro-32 and BLISS compilers
due to the amount of code in VMS which is written in those languages.

>> Do any of the DEC compilers generate code that executes on the stack
>> at runtime ?
>
> I doubt it.
>

Do any of the DEC compilers generate trampoline functions on the stack ?

> The point of making the stack non-executable is to make an attacker's job
> in exploiting security holes harder. If an attacker can upload exploit
> code (often called "shell code") into a stack buffer and run it there,
> that's easier than finding a way to upload the exploit code into heap
> memory.
>

VMS also has user-writable locations in a process whose contents survive
image rundown and which don't exist in other operating systems, for example,
the common area buffer and user logicals.

They were both executable on VAX and Alpha but at least the common
area buffer was apparently made non-executable on Itanium and above.
I would hope the user logicals were as well, but I don't know that
for sure.

Hopefully, anything else user-writable which survives image rundown
will also be non-executable these days.

Simon.

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

> 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.

Do you know who the authors of RMS and SSIO are? ;)
One of the people who created SSIO now has been working on RMS since 1975 (member of the initial VMS design team :)
Another example is Ruth Goldenberg, she came up with part of the SSIO design.

> 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.

Current status - SSIO works well and is in the field test phase. It's simple, fast, and fixes the problem for everyone, not just CRTL users.
The options for fixing this problem in CRTL that I know are complex and slow. Maybe your hack is quick and easy, I haven't looked at it carefully yet.

> One of the people who created SSIO now has been working on RMS since 1975 (member of the initial VMS design team :)
> Another example is Ruth Goldenberg, she came up with part of the SSIO design.
Good to know, pity they did not see this solution. But to restate what I said before, byte to XFC is a good thing particularly if it integrated into RMS, i.e. have XFC do the buffering for RMS.

> > 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.
> Current status - SSIO works well and is in the field test phase. It's simple, fast, and fixes the problem for everyone, not just CRTL users.
Apparently so, but no one has refuted that SSIO is NOT cluster safe, whereas the CRTL/RMS change is.

> The options for fixing this problem in CRTL that I know are complex and slow. Maybe your hack is quick and easy, I haven't looked at it carefully yet.
This is where we disagree, complex no, actually will probably simplify the code. If the changes to RMS are also done then even less complexity for CRTL.

What changes would I like to RMS, particularly with regards tp XFC.
- change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC
- change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA.
- fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data
- use the $ SET RMS values to directly impact XFC, block size/buffer/...
- and the list goes on, and has been around for decades

So Vitaly, do you work in the VSI/RMS space?

gt

On 2022-01-12, Greg Tinkler <tinklerg@gmail.com> wrote:
>> One of the people who created SSIO now has been working on RMS since 1975 (member of the initial VMS design team :)
>> Another example is Ruth Goldenberg, she came up with part of the SSIO design.
> Good to know, pity they did not see this solution. But to restate what I said before, byte to XFC is a good thing particularly if it integrated into RMS, i.e. have XFC do the buffering for RMS.
>
>> > 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.
>> Current status - SSIO works well and is in the field test phase. It's simple, fast, and fixes the problem for everyone, not just CRTL users.
> Apparently so, but no one has refuted that SSIO is NOT cluster safe, whereas the CRTL/RMS change is.
>
>> The options for fixing this problem in CRTL that I know are complex and slow. Maybe your hack is quick and easy, I haven't looked at it carefully yet.
> This is where we disagree, complex no, actually will probably simplify the code. If the changes to RMS are also done then even less complexity for CRTL.
>
> What changes would I like to RMS, particularly with regards tp XFC.
> - change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC
> - change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA.
> - fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data
> - use the $ SET RMS values to directly impact XFC, block size/buffer/...
> - and the list goes on, and has been around for decades
>

Let's assume for one moment that you could magically find a viable
solution that everyone else had missed. (Which I don't really believe,
but let's assume it anyway).

Question: What would be the overhead of going through RMS using
your solution instead of just using SSIO ?

IOW, how much slower would it be to go through RMS instead of
going through SSIO ?

Simon.

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

On Wednesday, January 12, 2022 at 2:23:07 PM UTC-5, Simon Clubley wrote:
> On 2022-01-11, John Dallman <j...@cix.co.uk> wrote:
> > In article <srkj4r$m7g$2...@dont-email.me>,
> > clubley@remove_me.eisner.decus.org-Earth.UFP (Simon Clubley) wrote:
> >
> >> However, at that time, John was planning to add this to the LLVM
> >> based compilers at some point. I don't know the current status of
> >> that.
> >
> > Most of that will come free with the LLVM compilers. The thing that will
> > probably be different is the error generation when checks are failed. On
> > OSes where I've used stack buffer overflow protection, failing a check
> > generally terminates the process.
> >
> In addition to the usual suspects, John was also talking at the time
> about seeing if this could be added into the Macro-32 and BLISS compilers
> due to the amount of code in VMS which is written in those languages.
> >> Do any of the DEC compilers generate code that executes on the stack
> >> at runtime ?
> >
> > I doubt it.
> >
> Do any of the DEC compilers generate trampoline functions on the stack ?

No code on the stack. The x86 stack is marked no-execute. The trampolines
are created by the linker with some image activator fix ups and then marked nowrite
before any code is executed.

For stack-smashing, it is still on the list. As we get native compilers in place, we'll
revisit it. Macro might be a touch harder with routines that branch between each
other.

On 1/12/2022 9:42 PM, John Reagan wrote:

> For stack-smashing, it is still on the list. As we get native compilers in place, we'll
> revisit it. Macro might be a touch harder with routines that branch between each
> other.

I offer up SYS$SHDRIVER as a test case . . .

--
-- Rob

On Wednesday, January 12, 2022 at 5:31:33 PM UTC-5, tink...@gmail.com wrote:
> > One of the people who created SSIO now has been working on RMS since 1975 (member of the initial VMS design team :)
> > Another example is Ruth Goldenberg, she came up with part of the SSIO design.
> Good to know, pity they did not see this solution. But to restate what I said before, byte to XFC is a good thing particularly if it integrated into RMS, i.e. have XFC do the buffering for RMS.

There needs to be a 'system' buffer, not a 'process' buffer.
For robustness that buffer is probably best on top of XFC, not inside.

You have been focussing on random updates. nice of database, irrelevant for typical usage today.
I think the more important problem to solve is shared appends and eof handling ( tail -f )

> What changes would I like to RMS, particularly with regards tp XFC.
> - change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC

READ/WRITE does NOT use (RMS) buffers. The user provide record (UBF on read, RBF on write)

> - change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA.

The current RFA already has a (32bit) block and (16 bit) byte offset.
I suppose you could add RAC=RFA and make $READ/$WRITE use the RFA fields, not the BKT.

> - fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data

$FIND has to read the data into the rms process buffer also.
It just does not move it to a user provided record buffer - a minor step in the scheme of things.
The biggest special thing about $FIND vs $GET is that $FIND only impacts the current record, not the next.
That is useful for updates. A program could be doing GET GET GET (all next 'blobs') then see some special data and decide to need a FIND and UPDATE for a random record before doing the next GET to continue reading a sequence. I find using two rabs for that more clear, more robust.

Hein.

Hi Hein

Always good to read your posts.

> You have been focussing on random updates. nice of database, irrelevant for typical usage today.
My understanding it is to get Postgresql running well on VMS, hence the need to random access.

> I think the more important problem to solve is shared appends and eof handling ( tail -f )
I though this was fixed is the current VMS versions...
Do you have a good suggestion for checking/getting the estimated EOF for a file from a program? If it is shared then it will only be a guess. I have not tried but $PUT with a 0 len record, or refresh the FAB and use that info.

> > - change $READ/$WRITE to use the MBC/Bucket buffers that RMS has, which would be XFC
> READ/WRITE does NOT use (RMS) buffers. The user provide record (UBF on read, RBF on write)
I known, but wouldn't it be good it READ/WRITE used the bucket/MBC buffers.

> > - change $READ/WRITE so they use byte offset. NB this is possible without change the RAB, just by adding a ROP (byteoffset) and using all the space available for RFA, i.e. RAB$Q_RFA.
> The current RFA already has a (32bit) block and (16 bit) byte offset.
> I suppose you could add RAC=RFA and make $READ/$WRITE use the RFA fields, not the BKT.
That would be good, combined with using the existing buffers.
Also we could extend the idea, the current RAB has
union {
unsigned short int rab$w_rfa [3]; /* record's file address */
struct {
unsigned long int rab$l_rfa0;
unsigned short int rab$w_rfa4;
} ;
} ;
short int rabdef$$_fill_4; /* (reserved - rms release 1 optimizes stores */
Effectively making it a Quadword, so why not have RAB$Q_RFA or RAB$Q_BOFFSET
No change to the layout of the RAB. We would need to flag this to RMS possibly by using ROP2 RAB$M_BOFFSET.
At lease from an API point of view RMS could support VERY large files. And yes there would need to be other engineering changes but these could be rolled out in a phased way. FAB will need to be fixed once GFS2 is available, so maybe FAB64$ with fab$l_alq -> fab$q_alq.

> > - fix $FIND so it will work with UDF files, so that $UPDATE can work without having the read data
> $FIND has to read the data into the rms process buffer also.
> It just does not move it to a user provided record buffer - a minor step in the scheme of things.
> The biggest special thing about $FIND vs $GET is that $FIND only impacts the current record, not the next.
> That is useful for updates. A program could be doing GET GET GET (all next 'blobs') then see some special data and decide to need a FIND and UPDATE for a random record before doing the next GET to continue reading a sequence. I find using two rabs for that more clear, more robust.

Yup, understand all that and agree, however I expected that $FIND would allow me to position the current record using RFA on a UDF file. It does not. It also means that creating pseudo record locks using $FIND probably will not work for the same reason. But this would be very useful.

gt

On 2022-01-13, Greg Tinkler <tinklerg@gmail.com> wrote:
> Effectively making it a Quadword, so why not have RAB$Q_RFA or RAB$Q_BOFFSET
> No change to the layout of the RAB. We would need to flag this to RMS possibly by using ROP2 RAB$M_BOFFSET.
> At lease from an API point of view RMS could support VERY large files. And yes there would need to be other engineering changes but these could be rolled out in a phased way. FAB will need to be fixed once GFS2 is available, so maybe FAB64$ with fab$l_alq -> fab$q_alq.
>

So you want to release an API claiming support for very large files _before_
actually performing the engineering work required ?

Do the DLM messages have the required extra 2 bytes going spare for your
expanded RFA ?

How would you implement this in a backwards compatible way at DLM level ?

When would you implement Prolog-4 for indexed files to support the required
larger internal pointers ?

Maybe I'm just old fashioned but I don't release an API for something
until _after_ I've done the engineering work. :-)

Simon.

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

> So you want to release an API claiming support for very large files _before_
> actually performing the engineering work required ?
No, yes. First it is about changing the RMS API to use byte offset, if only to make it easier for CRTL to do the right things.
With GFS2 of the horizon there needs to do a lot of re-engineering of RMS anyway, and this would be the start.
The RMS lock resource names will probably have the be changed, but I don't have any formal documents as to the structure of those.

gt

On 2022-01-15, Greg Tinkler <tinklerg@gmail.com> wrote:
> With GFS2 of the horizon there needs to do a lot of re-engineering of RMS anyway, and this would be the start.

GFS2, like VAFS before it, is currently on hold. No information has
been released about when (or if) future development of GFS2 will resume.

Simon.

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