Re: PROPOSAL: /proc/dev

Richard Gooch (rgooch@atnf.CSIRO.AU)
Thu, 1 Jan 1998 18:00:59 +1100


I wrote:
> So, my current thinking is:
>
> Device driver startup code registers the device entry, giving the name
> of the /dev entry, the permissions, ownership and so on as well as
> major&minor numbers for legacy disc-based /dev systems. Another
> parameter would be the name of the module to pass to kerneld when
> someone open()s /dev/someentry. The ctime of these entries would be 0
> (or perhaps system boot time).

Urg! I just realised I made a braino. Of course if driver modules are
not loaded at boot time, how can the module to load be added to the
devfs table for kerneld?
Well, I guess the default behaviour could be that devfs passes the
name of the /dev entry to kerneld, and leaves it up to kerneld to
worry about converting from "ttyS{0,1,2,3}" to "serial".

You could also have a /dev/TABLE or /proc/devtable entry to which you
could write thus:
# echo "serial=ttyS{0,1,2,3}"

> A system script could be used to change permissions of /dev entries,
> which is called by /etc/rc or whatever. This script uses a simple
> database to determine which devices to fiddle.
>
> Another system script is called when shutting down the system which
> scans /dev for entries with a ctime newer than 0|boot-time. Any
> modified entries will be written to the database mentioned above. The
> point of this is that when the sysadmin manually changes
> permissions/ownership from the shell, those settings will be preserved
> across reboots. The beauty of this scheme is that it needs bugger-all
> help from the kernel (read: no kernel bloat), and also doesn't require
> the kernel to ask a user-space daemon about permission details.

Another braino: if the /dev entry doesn't exist because the module is
not loaded yet. Solution: devfs maintains a table of device entries
and their permissions, for all entries which have had their
permissions changed from the default. If a device entry does exist
yet, the table entry is created anyway.
At shutdown, this table may be scanned by reading /proc/devprots or
some such.

Regards,

Richard....