[lkml]   [2002]   [Oct]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Switching from IOCTLs to a RAMFS
    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 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
    >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

    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
    * 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 :)


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:30    [W:0.024 / U:15.140 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site