Messages in this thread | | | Date | Fri, 2 Jan 1998 13:46:24 -0600 (CST) | From | "Patrick St. Jean" <> | Subject | Re: PROPOSAL: /proc/dev (new idea) |
| |
On 2 Jan 1998, Kjetil Torgrim Homme wrote: > Keep /dev on ext2 or whatever. Use that as your database to remember > owners and permissions. The major/minor could fluctuate, however.
In my opinion (please just take it as such), using a directory on disk as the database would not be ideal because. I'm not too knowlegable on the inner workings of the filesystem access stuff, but it seems to me that mounting a devfs on /dev would make the underlying /dev inaccessable.
> During boot, the kernel compiles a list of devices, and composes a > list somewhere in /proc, say /proc/devicelist [1]. The list could look > something like > > [driver devname maj min c/b owner:group perm] > > <snip list> > > and so on. owner:group and perm is just the _default suggestion_ from > the kernel.[2]
This I agree with, but shouldn't we list all of the devices that the kernel is _CAPABLE_ of? For example, a partitioned removable disk might throw that off... If we go this far, why not just make that a devfs instead of a /proc entry. It is a little more work to implement, but worth it. We create the entries in the devfs, using the "suggested" permissions from the kernel as a default (allowing changes). Maybe allow temporary chmod/chowns, and have some sort of flat file that can hold the changes. If we do things this way, changing root disks will throw us for a little loop, but so will using a filesystem /dev as a database. But we still have the reasonable defaults to fall back on. Also, it seems to me that a flat file with this info in it might be better from an administration standpoint since you jsut have to copy it in and run a small executable to be set up. It sure beats shell scripts with lots of mknod, chmod, and chown's.
> The hard part is kerneld. During boot, a module would register in the > device list, but with major:minor:type set to a magic kerneld device, > 10:255 or something. I hope that the kernel knows which inode (e.g., > "/dev/hdd") was accessed to cause kerneld to kick in -- this is a big > unknown for me.[4] >
This is exactly what I was thinking of when I decided against this approach. Why not jsut have the init function of the module call a devfs_register routine that the kernel has to create everything it needs?
Comments?
Pat
-- +----------------------------------------------------------------------------+ | Patrick St. Jean '97 XLH 883 psj@cgmlarson.com | | Programmer & Systems Administrator +1 713-977-4177 x115 | | Larson Software Technology http://www.cgmlarson.com | +----------------------------------------------------------------------------+
| |