Patrick Mochel wrote:
>>Is there a namespace doc or guideline we can look at?
>>(for existing nodes, sure, but more guidelines for future nodes)
>>
>>
>
>There's nothing official, at least not yet. I know that's a pretty crappy
>thing to say, but I've been this -><- close to doing for some time now..
>
hehe, that's cool :)
I'll just continue to point people to mochel@osdl.org when they ask
about a procfs alternative :)
>But, then we border on what exactly we want in sysfs. The original intent
>was to provide a simple ASCII-based interface, and _not_ provide device
>nodes.
>
>As things have matured, and more people want to move stuff out of procfs
>and replace ioctls with custom filesystem interfaces, I've questioned the
>original intent. In the end, I'm really ambivalent about whether to use
>sysfs or a custom filesystem for custom interfaces beyond the simple
>ASCII-based one. I'm not trying to either save or conquer the world with
>sysfs, and it would make my life a whole lot easier if no one at all used
>it. ;)
>
>But, I have arguments for both sides:
>
>If sysfs is used, there are the arguments I presented last time: once fs
>to mount, one API to create files in different subsystems, easier
>association between objects.
>
>While it's easy to create your own filesystem, either using fs/libfs.c
>helpers and/or fs/nfsd/nfsctl.c as your based, you still end up with a lot
>of replicated code. There will be copy-n-paste no matter what. I know it's
>not a really solid argument, but how much overhead is it going to incur if
>every subsystem and/or every object that belongs to each subsystem is
>exporting a filesystem instance?
>
>
Like I touched on in IRC, there is room for both sysfs and per-driver
filesystems.
I think just about everyone agrees that ioctls are a bad idea and a huge
maintenance annoyance. So, what is the alternate solution? IMO your
choices are presenting a device node for control via read(2), write(2),
and poll(2), or exporting a bunch of ASCII-controlled interfaces. While
I certainly agree with the overall strategy of sysfs, I can't see it as
being the best interface for wholesale replacement of groups of ioctls.
So that leaves per-driver filesystems, which have a bunch of benefits...
* allows for implementation of true character devices (chardevs),
something which sysfs was never intended to do
* solves module unloading problem, because filesystems must be mounted
before accessing and umounted before removal, which implies that there
will be no races at the open(2) level
* we all admit that sysfs doesn't attempt to solve similar problems as
devfs. so if one wants to do a sane device filesystem, a custom fs is
needed
* mount options are the current best solution for providing decent
default file permissions for dynamically instantiated file nodes. It
keeps policy in userspace while still providing dynamic file nodes in
the kernel. per-driver filesystems give you the granularity needed to
accomplish this.
* as fs/nfsd/nfsctl.c and libfs.c shows, you don't have to worry about
code bloat, so the only real overhead is the structures that are
involved in superblock/vfsmount operations
There were a couple other benefits I have forgotten by now :)
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Oct 31 2002 - 22:00:31 EST