ron minnich <rminnich@xxxxxxxxx> writes: > On Fri, Apr 23, 2010 at 8:36 PM, Serge E. Hallyn <serue@xxxxxxxxxx> wrote: > >> An fs actually seems overkill for two write-only files for >> process-related information. Would these actually be candidates >> for new /proc files? >> >> /proc/grantcred - replaces /dev/caphash, for privileged >> tasks to tell the kernel about new setuid >> capabilities >> /proc/self/usecred - replaces /dev/capuse for unprivileged >> tasks to make use of a setuid capability > > An fs is fine. > > To relate this to Plan 9, where it all began, might be useful. There's > no equivalent in Plan 9 to Linux/Unix devices of the major/minor > number etc. variety. In-kernel drivers and out-of-kernel servers both > end up providing the services (i.e. file name spaces) that we see in a > Linux file system. So the Plan 9 driver for the capability device > really does match closely in function and interface to a Linux > kernel-based file system. > > Hence, making devcap a file system is entirely appropriate, because it > best fits the way it works in Plan 9: a kernel driver that provides > two files. > > It's pretty easy to write a Linux VFS anyway, so it makes sense from > that point of view. > > Eric, that was a great suggestion. A fs provides user space policy control of naming. I.e. where the two files go. That can also be a very big deal. Especially when files are writable. You have no idea how much I am frustrated by sysfs right now, because it does not provide userspace policy control and instead mandates a sometimes inappropriate naming convention. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
