lkml.org 
[lkml]   [1998]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
Date
>> This follows the fundamental principal of keeping policy out of the
>> kernel (an argument which you yourself have advanced), and doing as much
>> as possible in usermode. Performance won't be an issue, since if the
---- deleted stuff ----

>The Only issue is that you then lose /dev on filesystems which don't
>support UNIX nodes (ie devfs on ms-dos partitions). Though there are
>other ways of achieving the same effect, so it's no big loss.


By all means keep policy out of the kernel. A deamon should be
notified any time any change occurs in the devfs config. This
includes:
- new device files
- change in permission/ownership
- new/removed sym-links

It will be the responsibility of the deamon to store, and
restore any configuration information. The deamon in user space
will decide whether to store this in inodes (if supported by
the base filesystem) or in a file (booted off msdos, or vfat),
or even ignore it (iso9660, and ramdisk).

It looks like the API can be very simple. All the kernel
needs to send is the filename(s) of the object(s) which
was(were) changed. Although we could also send a reason
why the deamon is notified
N:<filename> New,
R:<filename> Removed,
P:<filename> Permission changed.
(Any others?)

If it is a new file, the deamon will not have a record of it,
or will have a record of it being previously removed. If
it has an old record of the file, then the deamon can restore
any permissions.

If the file was just removed, the deamon removes it
from its data base, or instead it could mark it as removed
but remember its permissions. This allows transient devices
such as ZIP drives to keep their permissions.

If the file had its permission changed, the deamon changes its
record of it.

The problem with this setup is that old records can accumulate
over time. So the data base will grow big with unneeded
records. A method will be needed to purge these old records.
But this is again a policy question that the deamon will
have to address.



-
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.altern.org/andrebalsa/doc/lkml-faq.html

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