Re: vax wscons setting questions

[Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>]

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

> 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

Thanks,
---
Izumi Tsutsui