lkml.org 
[lkml]   [2008]   [Jun]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Is configfs the right solution for configuration based fs?
    On Sun, Jun 08, 2008 at 07:28:21PM -0700, Joel Becker wrote:
    > On Sun, Jun 08, 2008 at 02:25:36PM -0700, Luis R. Rodriguez wrote:
    > > I was really interested in looking to start a filesystem based
    > > approach for configuration of wireless a while back, an alternative to
    > > nl80211 if you will, but I stopped after I was told about some major
    > > issues with configfs. I forget the issues raised clearly so I'd like
    >
    > I'd love to hear about the issues as well.

    Here's a list of "known" issues I hear about with configfs.
    These are requests/complaints/etc I have gotten since it was merged.

    1) configfs should be sysfs

    The argument is that sysfs should somehow support the
    user-directed mkdir(2)/rmdir(2) lifecycle of configfs in addition to its
    usual functions. This, unfortunately, doesn't work. I sent a pretty
    detailed discussion of this to lkml the last time it came up, but here's
    a short summary. Number one, I tried this first. It got ugly fast.
    Number two, a goal of configfs is a simpler lifecycle than sysfs
    (understanding the lifetimes of config items). Adding an additional
    mode to the already complicated lifecycle of kobjects directly opposes
    this

    2) There needs to be a way to pin a config item

    configfs's ->drop_item() operation returns void - if it is
    called, your item must deactivate. This is in line with configfs'
    user-directed paradigm. However, sometimes another kernel subsystem is
    depending on that item - it will crash if the item goes away.
    After getting this beaten over my head a few times by good
    friends, I realized they were right. configfs now has
    configfs_depend_item() to allow subsystems to pin config items when
    necessary.

    3) configfs should support large attributes

    A configfs attribute can be a maximum of 4k in size. This fits
    the simple show/store methods cribbed from sysfs. However, more than
    one person has given a good reason for larger attributes, often lists of
    things.
    This isn't implemented yet, because I haven't come up with a
    good way to do it. seq_file works pretty well for the show side, but
    there is no seq_write() to match on the store side. I'd love to come up
    with a sane semantic and make it work. Consider it a TODO.

    Finally, this thread has presented
    4) easier definition of items, perhaps with macros like DEFINE_ATTR

    I think I have a __CONFIGFS_ATTR() macro, but it's nowhere near
    as nice as what sysfs has. This definitely could use some work, making
    configfs easier to use.

    That's what I have. I don't know if any of these issues were
    what you were worried about, Luis.

    Joel

    --

    "In the long run...we'll all be dead."
    -Unknown

    Joel Becker
    Principal Software Developer
    Oracle
    E-mail: joel.becker@oracle.com
    Phone: (650) 506-8127


    \
     
     \ /
      Last update: 2008-06-11 11:19    [W:0.026 / U:2.248 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site