[Info-vax] Console optiosn on x86

[Chris Scheers]

Stephen Hoffman wrote:
> 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.

Just because a "foreign" driver "expects" a "kernel" interface doesn't 
mean that it has to have an interface that is actually a "kernel" 
interface.  As long as a (currently undefined) "class" driver gives the 
"foreign" driver an interface that meets the foreign driver's 
requirements, it can be possible to do something useful.  This can be 
done without giving the "foreign" driver any actually kernel access, 
e.g., a sandbox or virtualization.

I never said that such a project is a reasonable or practical thing to 
do NOW.  I just said that it is possible.

But the possible has a way of becoming practical and then "obvious" as 
time and technology marches on.

So, for this particular example, I don't expect VSI to do anything on 
these lines now, but I think it is something that should always be on 
the "some day" pile and monitored.  At some point, it may become worth 
implementing.  (This is especially true when a client offers to pay for 
the capability.)

I've been writing emulators for 40 years now.  Most people would 
consider emulators only useful in the last 10 years.  (And some people 
feel that they still aren't useful.)

But starting about 35 years ago, I saw emulators start to be useful in 
commercial settings, even when they were 1/1000th the speed of the 
emulated hardware.  When the right conditions converge, there are 
surprising things that can become useful.  It all depends on your goal.

-- 
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360            Internet: chris at applied-synergy.com
   Fax: 817-237-3074