Thanks for your reply again! See comments inline...
Joel Becker wrote:
I fully agree with the idea of configfs not being allowed to destroy
user-created objects. OTOH, while configfs is described as a filesystem
for user-created objects under user control, compared to sysfs as a
filesystem for kernel-created objects under kernel control, configfs
_does_ permit kernel-created objects in a limited way (by filling in
struct config_group->default_groups), and these objects can only be
destroyed again by the kernel, and not by the user.
They are not created by a kernel action. They are created as a
direct result of a user action. The user must mkdir(2) the parent in
the chain. Only then do these default_groups appear. Contrast sysfs,
where filesystem structures can be added at any time, from any codepath,
via the sysfs in-kernel API.
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.
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:
For another example, and directly related to above link, suppose
having an object with a number of attributes, one of them being
called 'type'. Dependent on the value of 'type' this object may
contain a particular type of sub-object (with type-dependent
attributes). E.g. 'type' may be empty | 'a' | 'b' | 'ab', then
dependent on this there should be 0 or 1 directories called 'a',
and 0 or 1 directories called 'b'. Doing it this way means that
while the user decides what sub-directory/-ies the object has, he
does not create them (directly) - it is the kernel which creates
the object, and as such it is also the kernel only which is
permitted to destroy the object again - by the user writing a
different value to the 'type' attribute (or clearing it). sysconfs
could solve this.
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. ;-)
If you want the following:
# cd mydir
# ls -l
-rw-r--r-- 1 root root 0 2006-12-28 07:11 type
# echo 'ab' > type
# ls -l mydir
drwxr-xr-x 2 root root 4096 2007-01-08 14:21 ab
-rw-r--r-- 1 root root 2 2007-01-08 14:21 type
# echo '' > type
# ls -l mydir
-rw-r--r-- 1 root root 0 2007-01-08 14:22 type
you're never going to get it from configfs. You should be using
sysfs.
Hardly. sysfs doesn't allow the user creating directories. :>
As such I don't understand fully why one doesn't want to merge sysfs and
configfs (let's call it sysconfs for now) in such a way that it allows
_both_ user- and kernel-created objects, with user-objects only allowed
to be destroyed by the user and kernel-objects only by the kernel.
The programming interface is very, very different. Check out
historical messages on this topic:
http://www.mail-archive.com/[email protected]/msg95708.html
http://www.mail-archive.com/[email protected]/msg95711.html
http://www.mail-archive.com/[email protected]/msg95714.html
http://www.mail-archive.com/[email protected]/msg95717.html
Well, you could still use type (user object/kernel object) dependent
structure pointers?
Often however, what you want is that an object may contain 0 or 1 other
objects. If ->make_item()/make_group() would allow returning a
meaningful error code the kernel could deny creation of a 2nd object
other than by pretending to be out of memory.
You make a reasonable case that ENOMEM isn't always the error
you want, but perhaps we can add a better umbrella error code? I'm wary
of introducing PTR_ERR() or any other complexity if we don't _need_ it.
I'm all for thoughts on possibly compromises.
I was thinking about
ssize_t make_item(struct config_group *group, const char *name, struct
config_item **new_item)
with return value 0 meaning no-error.
Sure, it's another way to go, but it's effectively the same
thing.
Well, you don't need PTR_ERR().
I was thinking about having symlinks in a directory and deriving the
order by the symlinks' filenames, too. I dismissed it originally for two
reasons. First, I didn't see how to keep the order when some link gets
deleted, e.g. there's 1,2,3 and then link 2 gets deleted. Now, thinking
about it again, I can simply keep a ordered linked list internally, and
therefrom remove the node for link 2. But it's still not perfect,
because how do I insert a link between filenames 1 and 2? Ok, I have to
delete all symlinks first and then rebuild them, and in the end it's
like rewriting a params_list attribute file... except that it's not
atomic. Second, a simple params_list file seems a lot more easy to
handle from the user perspective... simply open the file with an editor,
add or delete an entry, save it, close it. I don't know which method is
better, the one described here with a params/ subdirectory containing
symlinks with their order derived from their filenames, or method 2)
from below with simply having a params_list file where params entries
get renamed to <params removed> but are still valid until the user
rewrites the params_list file.
Why not both? You need the reference, and the reference must
come from a userspace action. While a set of ordered names would be
easy for some folks, maybe it isn't for you. So, the userspace process
first symlinks all dependant parameters, thus taking a reference. Then,
they write to params/order to order them. If they remove a symlink, you
just delete the dentry from params/order.
# cd object/params
# ls -l
-rw-r--r-- 1 root root 0 2007-01-08 14:22 order
# ln -s ../../params/param1 .
# ln -s ../../params/param2 .
# ls -l
-rw-r--r-- 1 root root 0 2007-01-08 14:22 order
lrwxrwxrwx 1 root root 19 2007-01-08 15:30 param1 -> ../../params/param1
lrwxrwxrwx 1 root root 19 2007-01-08 15:30 param2 -> ../../params/param2
# cat order
# cat >order
param2
param1
^D
# cat order
param2
param1
# rm param2
# ls -l
-rw-r--r-- 1 root root 0 2007-01-08 14:31 order
lrwxrwxrwx 1 root root 19 2007-01-08 15:30 param1 -> ../../params/param1
# cat order
param1
Note that you don't need a "<param2 deleted>" placeholder in
'order'. Userspace explicitly removed the symlink, they should know
what they did.
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.
Well, I hope I've come up with a few ways of doing this that
perhaps you'll either like or find inspiring. One thing to remember is
that, while I'm using shell commands to show the configfs operations, in
reality there'd be a wrapper program for your user. You want the actual
user to be given a tool that speaks what they *want* to do, not how it
actually gets done.
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...
Joel
Thanks, Michael
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
