Re: Finding the slot in the ioconf table a module attaches to?

[Brian Buhrow <buhrow%nfbcal.org@localhost>]

	hello. Mouse's question is the same as mine.  It's fine to have a dynamically assigned
major number for the module, but since we don't have a dynamic /dev, that number needs to be
static enough so that devices can be created in the /dev tree.  The idea that one can request a
prefered major number from the kernel in the module itself partially mitigates this issue in
the sense that one can be pretty confident that one will get the same number when ever the
system boots on a given system, but it does mean that a kernel update or new device driver
statically linked into the kernel, or if the ordering of the module load changes, the major
device number assigned to a given module and the number on the node in the /dev tree can get
out of sync.

	It looks like the devpubd(8) program partially solves this problem, at least for the
installation of a new module.  It can be configured, in conjunction with modifications to the
/dev/MAKEDEV script, to create new device nodes.  
However, as currently implemented, devpubd doesn't pass the major number to the MAKEDEV script.
So, the MAKEDEV script would need to have some intelligence about how to get the major number
from the kernel, probably by reading a sysctl variable.  Also, it doesn't look like the devpubd
program currently deletes any devices from the /dev tree.  'This is a problem since if the
major number changes, the MAKEDEV script, as currently implemented and as devpubd currently
calls it, won't modify an existing device in the /dev tree.

	Having said that, it looks like the easiest way to make this problem better is to extend
the functionality of the devpubd program to allow it to dynamically add and delete devices from
the /dev tree and to provide a standardized mechanism for extracting the major number from the
kernel and passing it to the MAKEDEV script.

-thanks
-Brian