[Info-vax] Console optiosn on x86

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri May 1 13:42:40 EDT 2015


On 2015-05-01 17:29:26 +0000, Chris Scheers said:

> Bob Koehler wrote:
>> I thin you'ld have to drill holes thourgh the kernel to get it to work. 
>>  The resuting swiss cheese is something I'd not care for.
> 
> Not necessarily.  It's something like the current class/port 
> architecture.  A port driver is not a VMS driver.  It talks to the 
> class driver, which is a VMS driver.

While it's true that port drivers can and do have unique interface to 
their respective class drivers, that doesn't help with the interfaces 
that the "foreign" drivers expect for kernel interfaces and memory 
management and the rest, and for performing and coordinating with 
device-level access.

While there was some work to allow certain mbuf-based kernel interfaces 
for porting and using certain Tru64 UNIX device drivers — arguably this 
work being more a case of using common kernel code for specific device 
drivers than specifically "port" jackets for and a port of an arbitrary 
Linux or Unix driver — you're inherently contending with what the 
"foreign" drivers expect and need.

Probably the biggest area of interest for this (theoretical) class-port 
approach involves the graphics device drivers, and that's an area where 
you really want and need the drivers to be fast, and where the OpenVMS 
and DECwindows device driver interfaces and requirements are — in 
comparison to console serial drivers — comparatively complex.

As a vendor, VSI also gets to deal with the copyrights and software 
licenses involved, if they should wrap and incorporate third-party code.


-- 
Pure Personal Opinion | HoffmanLabs LLC




More information about the Info-vax mailing list