Re: Mark module tun obsolete

[Paul Goyette <paul%whooppee.com@localhost>]

On Sun, 24 Mar 2019, David Holland wrote:

> On Sun, Mar 24, 2019 at 04:59:58PM +0800, Paul Goyette wrote:
> > Hmmm, checking the cvs history it seems that I added this dummy module
> > for a specific reason.  :)
>
> Surely there's got to be a better way to set this up than creating
> dummy modules... there's already a translation table in there with the
> device name that gets used for autoload; there could be two names in
> there or a flag that says to prepend "if_" or whatever else.
>
> Or the name could go directly in struct cdevsw. I'm not clear on what
> the point of the translation table is.

From looking at this, it would seem that modifying the conversion
table stuff could get messy...

Routines {c,b}devsw_name() use the conversion table devsw_conv.  The
table devsw_conv is initialized in a machine-generated source file
obj/sys/arch/${ARCH}/compile/${KERNEL}/devsw.c and gets updated by
stuff in kern/kern_devsw.c (at least in the devsw_attach() routine).

It looks like config(1) generates the devsw.c file.  I don't think
config(1) has any clue if the device is a network interface (thus
requiring the "if_" prefix).  We could theoretically teach config(1)
to differentiate between network devices and others, and then to
create a second name for module loading.  We'd also have to teach
devsw_attach() to differentiate when extending the table.

There several direct references to the conversion table:

# find $SRC/sys -printx | xargs grep -c 'devsw_conv' | grep -v ':0$'
./kern/init_sysctl.c:7              <--- for kern.drivers
./kern/subr_devsw.c:47
./miscfs/procfs/procfs_linux.c:10   <--- for procfs device list
./miscfs/specfs/spec_vnops.c:2      <--- comments only
./rump/include/rump-sys/vfs.h:1
./rump/librump/rumpkern/devsw.c:3
./rump/librump/rumpvfs/devnodes.c:2
./rump/librump/rumpvfs/rump_vfs.c:3
./sys/conv.h:1


Another alternative might be to have the specfs_vnops.c code try to
load _both_ forms of the module name (with/witwhout prefix).  While
this would be a bit more overhead, autoloading of device drivers is
not exactly a frequent event.  :)  And there is precedent for having
the kernel autoload more-than-it-needs (see the code in kern_exec
that tries to load ALL POSSIBLE emulation modules).




+--------------------+--------------------------+-----------------------+
| Paul Goyette       | PGP Key fingerprint:     | E-mail addresses:     |
| (Retired)          | FA29 0E3B 35AF E8AE 6651 | paul%whooppee.com@localhost     |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoyette%netbsd.org@localhost   |
+--------------------+--------------------------+-----------------------+