lkml.org 
[lkml]   [1999]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: PUBLIC CHALLENGE: (was RE: devfs again, (was RE: USB device alloc ation) )
Date
On Sun, 10 Oct 1999, Horst von Brand wrote:

>OK, I see the code for chmod(1) now:
>
>
> if(file is named /dev/whatever) { /* This is _hard_ to find out */
> go update /etc/devices.perms
> }
> else {
> ...
> }
>
>Never thought of that brilliant solution. Just have to fix the obvious race
>in there. And think about what to do if /etc/devices.perm is inaccessible
>(gone, broken, ...).

I'm astonished! Such brilliance!

Surpisingly enought, such brilliance _is_ already in the kernel
(no need at all to change chmod(1) or anything else, for that matter).
We call it VFS.

Chmod, and other filesystem-related system calls, already do
something of that sort, so the myriad of programs in userland don't
have to. In a nutshell, chmod does

do some common operations that are independent of the specific FS;
locate the filesystem handler for the named file;
call the FS's chmod "method";

The FS's specific "methods" are free to implement the functionality
as they see fit, according to the underlying FS model they are
written to support.

No change to chmod(1), as chmod(2) already has the required
functionality.

Of course there are obvious (and not so obvious) races in such a
scheme. Alexander Viro has been working on VFS, trying to resolve
all the races. But those races _are_ solvable, or else we must
conclude VFS was a bad idea to start with.

I fail to see anything devfs-specific in this very particular line of
reasoning.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

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