[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