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
