[lkml]   [2007]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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

    > 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

    > 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



    "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
    Phone: (650) 506-8127
    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: 2007-01-23 03:11    [W:0.032 / U:6.504 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site