I agree. Loading and unloading is 'orrible. The latest thinking is:
Device driver startup code registers the device entry, giving the name
of the /dev entry, the default permissions, ownership and so on as
well as major&minor numbers for legacy disc-based /dev systems. The
ctime of these entries would be 0 (or perhaps system boot time, but
*not* module load time). The major&minor numbers that get reported via
the VFS will be 0,0.
If a process tries to open() an entry in /dev which does not exist,
devfs passes the name of the entry to kerneld. It is up to kerneld to
convert filenames to modules (i.e. "ttyS{0,1,2,3}" to "serial").
The system boot script checks it's /dev protections database and uses
chown(2) and chmod(2) to modify permissions. If an entry does not
exist, the script must first call mknod(2) which will create a
"placeholder" entry. This placeholder will appear to have major&minor
of -1,-1 or some such. When chmod(2) is called the ctime is updated.
When a device driver registers a device entry and a placeholder entry
is already there, the entry is filled in and the major&minor will
appear to be 0,0.
Once an entry exists (be it a placeholder or not), it stays until
reboot. When dev_unregister () is called, the major&minor will appear
as -1,-1 again. However the ctime will persist. This is how a shutdown
script will tell which /dev entries have had their modes changed,
without need to refer to the driver module to determine the default
mode. Further, this scheme means that once the sysadmin set the mode
for a /dev entry, it persists even if the default mode changes with a
new driver release. Also, this scheme allows the sysadmin to change
modes from the shell and have those changes persist across reboots.
If you worry about a system crash loosing the mode/uid/gid
information, just run a cron job every hour or so to grab a snapshot
of the info.
Note also that an attempt to open(2) a placeholder entry (i.e. one
where the device driver is not currently loaded) will also cause a
message to be sent to kerneld.
In the worst-case scenario where all drivers are loaded, the number of
*available* devices will probably be only 100 to 200, so the kernel
memory consumption should be pretty modest, only a few pages or so,
even if we need a full VFS inode for each entry (244 bytes). I'm
hoping to avoid creating full VFS inodes anyway. I figure each entry
should come in under 64 bytes.
Regards,
Richard....