[Info-vax] DECnet Phase IV broken after VSI update

[David Jones]

On Wednesday, November 3, 2021 at 11:51:05 PM UTC-4, Lawrence D’Oliveiro wrote:
> On Thursday, November 4, 2021 at 1:19:18 PM UTC+13, Arne Vajhøj wrote: 
> >> ...  So there is some kind of extra layer on top 
> >> of the kernel driver, and you are not supposed to access the latter 
> >> directly. 
> >> 
> > Yes. 
> > 
> > PTD$ user mode library ---> some VMS kernel code ---> driver code
> And note the implication that bad things could happen if you $DASSGN the channel without calling PTD$DELETE. Or if you tried to $QIO yourself without using PTD$READ/WRITE. 
> 
> I wonder why it was necessary to do it this way?

Most of PTD$ code runs in kernel mode with some at elevated IPL. The PTD$CREATE call 
creates a buffer object for the buffer you supply so that the buffer (and its S0 address)
stays locked in memory. PTD$READ/WRITE queue request packets directly to FTDRIVER,
skipping some of the overhead of $QIO processing.

I wonder if DECnet would be able to use a pseudo-terminal for a DDCMP link and have
the control program tunnel the packets over a secure link of some kind. Unlike LDRIVER,
unfortunately, PTD$CREATE doesn't let you specify the unit number of the created
device.