[Info-vax] TUN/TAP Like driver any pointers ?

[Stephen Hoffman]

On 2019-09-10 12:47:31 +0000, Simon Clubley said:

> On 2019-09-09, Michael Moroney <moroney at world.std.spaamtrap.com> wrote:
>> Linux drivers are quite different from VMS, often they run in user mode.
> 
> The Linux driver model is indeed extremely flexible.

Simpler in various ways, too.

> I wish the VMS driver model was as flexible.

Same here.  And I've written a number of OpenVMS device drivers.

> You can unload drivers and reload them without having to reboot.

That'd be handy for software updates and uptime, certainly.

For development, remote debugging is probably the better approach.

And I'd rather use remote debugging rather than debugging drivers 
locally, as unstable drivers can and do cause crashes.

Easier to avoid unnecessarily re-establish a development and debugging 
context on each reboot.

That does mean more licenses for OpenVMS, though.

> For some classes of drivers, you can implement them either in kernel 
> mode for performance purposes, or you can implement some of them in 
> user mode when you want ease of development and when performance is not 
> that critical.

Years ago, connect-to-interrupt was the rough analog of this on OpenVMS,

> You can add in your own filesystems as you wish.

FUSE, etc.

https://en.wikipedia.org/wiki/Filesystem_in_Userspace

> You can implement all kinds of specialist network related protocols via 
> the TUN/TAP drivers.

Ayup.  And among many other clients, hardware emulators use these.

>> VMS drivers can be quite complex.
> 
> Is this "required" or "artifical" complexity ?

It's complexity, but whether it's artificial?

Creating anew and revamping device drivers is no small project.

Making programming interfaces more powerful and simpler is surprisingly 
difficult.

I've found that simplicity is well worth the investment.

This simplicity and consistency was a key part of the foundation of 
then VAX-11/VMS.

And it'll increasingly be the future of a successful and resurgent OpenVMS.

Downside: some of the older stuff will have to go.

> It's been over a decade since I wrote a VMS device driver for a PCI 
> device on Alpha as a hobbyist project so I don't remember the details, 
> but the impression I have been left with is that it was harder to do 
> the same thing in a device driver on VMS when compared to Linux.

It is far more complex, yes.  There've been efforts to do simpler 
drivers and simpler interfaces.  Connect to interrupt was one. The C 
system programming work was another.

Looking around, plug-ins are becoming more common on various platforms, 
as classic kernel drivers have system-wide access. Which works well for 
some things, and not so good for bugs, such as the kernel-mode floating 
point register corrupter that was around a ~decade or so ago. That bug 
was fun to find, too.  Device connections via PCIe (and Thunderbolt) 
and USB, for instance. And third-party drivers for custom PCIe devices 
are fairly rare on OpenVMS.

> It may also be that I simply wasn't used to the VMS device driver 
> structure, and I seem to recall not having all the information I 
> needed, so I don't know how accurate the perception I have been left 
> with actually is.

It's complex, certainly.

> For one simple example, do VMS drivers have access to a VMS version of 
> printk() (not printf()!) so that you can easily issue debug messages in 
> kernel mode ?...

There's the tr_print mechanism for printing from kernel-mode device 
drivers and other kernel-mode code.  Albeit, undocumented.

https://www.hoffmanlabs.com/vmsfaq/vmsfaq_017.html#progtr

It'd be nice if this printing mechanism was updated and better 
integrated into the kernel C library, but that's fodder for another 
discussion.

> 
>> I'd suspect the "easiest" way to implement something like this is to 
>> implement most of the code as an ACP so it has process context where 
>> needed, and a base pseudo-device driver which calls into it.  Writing 
>> ACP code is also poorly documented and I think was generally 
>> discouraged.
> 
> Try "not documented" :-), at least as far as someone like myself is 
> concerned. ACPs are an interesting possibility, but which are a 
> non-viable option due to the lack of documentation and examples.

Ayup.  Undocumented. The "best" book on ACPs is the late Jamie 
Hanrahan's VMS Advanced Driver Techniques book, long out of print.  
Having written my first ACP-and-driver package a month or two before 
that book became available, there were a few errors in that book, 
though I don't recall the details.  But it was pretty good.  There are 
a few ACPs on the Freeware or the old DECUS library stuff.  (There've 
been previous discussions of ACPs here in the comp.os,vms newsgroup, 
for those that are able and willing to search for it.)

ACPs are handy for stuff that is necessarily in user mode, but I'd tend 
to stay with kernel for other stuff and avoid the mode changes and the 
buffer copies.

For what some other folks are doing, such as migrating TLS into the 
kernel: https://svnweb.freebsd.org/base?view=revision&revision=351522




-- 
Pure Personal Opinion | HoffmanLabs LLC