[Info-vax] DCL and scripting

[Stephen Hoffman]

On 2018-12-12 18:41:18 +0000, Simon Clubley said:

> I've never seen the VMS source code so I don't know the answer to this, 
> but is the terminal driver line editing code unmaintainable because 
> someone tried to be "clever" when writing the code and hence caused 
> maintainence problems later on when changes were required, or was it 
> simply that someone tried to fit something into the kernel that should 
> never have been placed in the kernel in the first place ?

Operating systems are replete with trade-offs.  The associated designs 
and the inevitable trade-offs in each operating system age.  At 
different rates.

The terminal driver stack and the storage driver stack are effectively 
enormous input-parsing state tables.  Running in kernel-mode.  Written 
in iterative, procedural Macro32, Bliss, or C code.  Without the 
benefit of state-table tooling.

Drivers aren't the only spot that's been late to adopt tooling.  DCL 
had its own process threading implementation up until the Itanium port. 
 Use of KP Threads was then implemented.  More than a little of OpenVMS 
doesn't leverage now-available libraries and tools.  Or doesn't provide 
the libraries and tools.

The terminal class and port design does remain a quite good and useful 
approach, though I suspect the API might look very different if it were 
rebuilt in this era.  But with multiple port drivers present, 
substantive changes to the class driver or the class-port interface 
incurs large testing efforts.  Or the deprecation of various 
communications or storage hardware.  Or both.

In the era that VAX/VMS arose, process creation and interprocess 
communications and the associated designs lacked performance, and 
buffer copies were ubiquitous in buffered-I/O device drivers and in 
many of the app designs.  Having everything in the kernel—spread across 
three modes/rings—was appropriate and had (and has) acceptable 
performance for most applications.  There's been more than a little 
hardware misbehavior fixed in software, too.  Some of the chipsets 
are... buggy.

The maintenance problems here are not unexpected, and arise from 
decades of device-specific accretions and work-arounds, and of decades 
of API assumptions lurking in vendor and third-party app code.

In a wholesale redesign in this area and in this era, I'd look to use 
something closer to seL4 and process-based isolation, at a migration to 
state machine designs, and with the intent of never copying a buffer 
around.  With much thinner "drivers".  But that's not going to happen.  
Well, this refactoring sorta did happen, and it was called DEC MICA.




-- 
Pure Personal Opinion | HoffmanLabs LLC