lkml.org 
[lkml]   [2007]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: configfs: return value for drop_item()/make_item()?
    On Mon, Jan 22, 2007 at 01:35:36PM +0100, Michael Noisternig wrote:
    > Sure, but what I meant to say was that the user, when creating a
    > directory, did not request creation of such sub-directories, so I see
    > them as created by the kernel.

    Ahh, but userspace did! It's part of the configfs contract.
    They've asked for an new config item and all that it entails.

    > If you argue that they are in fact created by the user because they are
    > a direct result of a user action, then I can apply the same argument to
    > this one example:
    > ...
    > >This is precisely what configfs is designed to forbid. The kernel
    > >does not, ever, create configfs objects on its own. It does it as a
    > >result of userspace action.
    >
    > No. The sub-directory only appears as a direct result of the user
    > writing a value into the 'type' attribute. ;-)

    Ok, you're stretching the metaphor. Writing a value to a "type"
    attribute is, indeed, a userspace action. However, configfs' contract
    is that only mkdir(2) creates objects.
    We're not trying to create the do-everything-kitchen-sink system
    here. That way lies the problems we're trying to avoid. That's why
    configfs has a specific contract it provides to (a) userspace and (b)
    client drivers.

    > >you're never going to get it from configfs. You should be using
    > >sysfs.
    >
    > Hardly. sysfs doesn't allow the user creating directories. :>

    sysfs certainly supports your "echo b > type" style of object
    creation. You're type_file->store() method gets a "b" in the buffer and
    then does sysfs_mkdir() of your new object directory. Here, the kernel
    is creating the new object (the directory).

    > Well, you don't need PTR_ERR().

    Sure, you could use **new_item. It's the same complexity
    change.

    > That's an interesting other solution, however it seems a bit redundant
    > (params are referenced by links as well as in the 'order' attribute
    > file) and not as simple as my method 2). I guess, for now, in lack of a
    > convincing solution, I will implement method 2) as the one easiest to
    > adapt to given my current code base.

    But they are not referenced by the order file. It's just an
    attribute :-) Really, you can look at it either way. But configfs has
    a specific perspective based on its contracts, and so it works within
    them.

    > Hm, I had envisioned the user to fully configure the module via file
    > system operations only. Now if the user is supposed to use a wrapper
    > program this sheds a different light on all those
    > what's-the-best-solution issues...

    Certainly the user can do the configuration by hand. It will
    always work. But why make them understand your userspace<->kernel API
    when you can just provide a tool? They're all going to script it up
    anyway.

    Joel

    --

    "The doctrine of human equality reposes on this: that there is no
    man really clever who has not found that he is stupid."
    - Gilbert K. Chesterson

    Joel Becker
    Principal Software Developer
    Oracle
    E-mail: joel.becker@oracle.com
    Phone: (650) 506-8127
    -
    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/

    \
     
     \ /
      Last update: 2007-01-23 03:11    [W:0.025 / U:29.164 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site