lkml.org 
[lkml]   [1998]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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 |
+----------------------------------------------------------------------------+


\
 
 \ /
  Last update: 2005-03-22 13:41    [W:0.157 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site