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: [EMAIL PROTECTED]
Phone: (650) 506-8127
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
