ragge@ wrote:
and even src/sys/arch/vax/uba/dmf.c has not been ported from 4.4BSD?
https://man.netbsd.org/vax/dmf.4
Hm, I try to recapture more about this :-)
I used DMF32 on 750's in the mid-90's. Compiling the driver from 4BSD
was trivial back then, but it could not be checked in in NetBSD due to
the licensing issues.
There is no need to revert anything, better to try to be as similar as
possible as other ports.
Sure, I guess then there is no actual user (except you :-) of dmf(4)
with tty[EFGH][0-7] nodes.
I'll update src/etc/etc.vax/MAKEDEV.conf to clarify how these
tty[EFGH] should be handled:
- explicitly comment out dmf(4) (and dmz(4)) entries
- denote that tty[EFGH] were reserved for dmf(4) but it had not
been imported, so now tty[EFGH] are used by MI wscons
- new tty node names should be assigned once dmf(4) is committed
Yes, please do so.
I asked core@ some years ago if the MBA routines from 4BSD could be
checked in, but they responded that the licensing issues were
unfortunately still unclear.
Hmm. I guess there are a lot of cleanup task to update 4.4BSD
derived sources for modern NetBSD, so maybe it's worth to rewrite
it based on qvaux.c etc.?
It looks most vax serial drivers call tty(4) layer functions
(t_linesw->l_rint() and t_linesw->l_start() etc.) from
interrupt handlers, but I guess nowadays we have to use
softint(9) to avoid MI locking issue.
I had several trouble on luna68k and updated sio(4) driver
derived from 4.4BSD to use softint(9):
https://github.com/NetBSD/src/commit/bc63cd4
Quite unlikely that someone would bother writing a device driver for
it.