Re: PROPOSAL: /proc/dev

Linus Torvalds (torvalds@transmeta.com)
Thu, 1 Jan 1998 11:31:00 -0800 (PST)


On Thu, 1 Jan 1998, Richard Gooch wrote:
>
> Hi, all. My recent work on the /proc/mtrr interface has gotten me
> thinking about an old discussion: configuring /dev entries. Instead of
> complicated schemes for determining what devices are available and
> automagically creating /dev entries, how about creating entries in
> /proc/dev instead?

Two quick notes:

- I think it should be a separate filesystem type. It was a mistake in
the first place to overload /proc as much as we did, we shouldn't
continue that (I should really have split out the "per-process" things
and the "global" things to two separate filesystems).

Note that being two filesystems doesn't mean that it can't have shared
code: they might even be compiled together. But it should be possible
to mount the device filesystem independently of the /proc filesystem.

Note that making it a separate filesystem actually makes some things
easier: you don't have to worry about clashing inode numbers with the
normal /proc filesystem. That's actually one reason I'd like to split
up even the stuff we have now - the inode numbering "logic" (and I use
the term very losely indeed) is so painful.

- You need to handle permissions some way. The obvious way is to make the
permissions very very restrictive and allow root to do a "chmod/chown"
on the files and remembering the new values. I see you suggested
options to the kernel, but that only works with modules and is very
static anyway (having to unload and re-load a module just to change the
permissions of the device file? No thank you).

Finally, I think it would be good to try to use the dcache to actually
remember the names of the files rather than having a separate data
structure for names. Too bad we didn't have the dcache when the original
/proc was done, but these days you could actually populate /proc with the
generic dcache functions:

/*
* Add and remove a /proc entry to the proper directory
*/
proc_file_add(struct dentry *dir, struct dentry *newfile)
{
newfile->d_parent = dget(dir);
d_add(newfile);
}

proc_file_remove(struct dentry *file)
{
d_drop(file);
}

/*
* readdir is trivial..
*/
int proc_readdir(struct file * f, void * dirent, filldir_t filldir)
{
int pos;
struct dentry * dir = f->f_dentry, * dentry;
struct list_head * child;

/* Jump over the ones we've seen.. */
pos = filp->f_pos;
child = dir->d_child;
do {
child = child->next;
/* end of directory? */
if (child == &dir->d_child) {
return 0;
} while (!pos--);

/* start feeding the next ones.. */
do {
struct dentry * dentry = list_entry(child, struct dentry, d_child);
int error = filldir(dirent,
dentry->d_name.name,
dentry->d_name.len,
f->f_pos,
dentry->d_inode->i_ino);
if (error)
break;
f->f_pos++;
child = child->next;
} while (child != &dir->d_child);

return 0;
}

/*
* Look-up is even more so - we only have
* the stuff that is already in the dcache,
* so we can always just return ENOENT..
*/
int proc_lookup(..)
{
return -ENOENT;
}

....

Anyway, something like the above would be very powerful and avoid keeping
filenames around anywhere but in the dcache..

Linus