Date: Wed, 2 Apr 1997 17:54:33 +1000 (EST) From: proff@suburbia.net To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: hackers@freebsd.org Subject: devfs Message-ID: <19970402075433.19722.qmail@suburbia.net> In-Reply-To: <28836.859954625@time.cdrom.com> from "Jordan K. Hubbard" at "Apr 1, 97 08:17:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
> > We *have* a well designed and thought out device interface: devfs. > > Well thought-out, yes. Finished, no. :) > > > I have *no* idea what is preventing you from making it the default > > mechanism. > > 1. It has no persistance and a number of people have already told me directly > (some of them at USENIX, immediately following Julian's talk on DEVFS) > that we will be roundly castigated and screamed at in the various > public forums for breaking /dev's historical behavior if we don't make > persistance work and work *completely transparently*. Let's say > somebody has a "securify" script that they run on a new system as part > of their security auditing process. It's been running on FreeBSD > systems since 2.0, making sure that tape drives and CDROMs and such > all have sane perms (or maybe even some sort of "insane" perms which are > part of a more elaborate ownership scheme which they like), and now > suddenly with FreeBSD 4.0 or whatever they find that everything the > script does on these new systems is undone after a reboot. Say what?? > > Jordan Your arguments about state are very true. I see a few ways around them. 1) accept that devfs in it's present form is a kludge. Move all the default permissions and device numbers into a sysctl hierarchy. This hierarchy is then used to create names in /dev. Add a new ufs file type: S_IFLNKDEV. When a namei occurs on what this pseudo-symlink points to, it looks up name in the sysctl and returns the inode of the "symlink" with device numbers filled in. The mode, ownership, time stamps, and everything but the major/minor numbers are taken from the LNKDEV entry itself. In effect this just replaces major/minor numbers with a string. 2) code a light "permission union" file system. this file system type would work like unionfs, but with file permissions only. Mount devfs on /dev and the permission union over the top. When ever permissions are changed from the default an entry is created in the upper layer. Problem: multiple permission views of individual devices are not supported using this scheme. devfs is an ill-thought out concept. If the desire is to return device driver status information then, then sysctl is the appropriate venue. If the desire is to bypass numeric (major/minor) numbering limitations then 1) is more appropriate. Cheers, Julian.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970402075433.19722.qmail>