lkml.org 
[lkml]   [2007]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectconfigfs issues
Hi all,

I've got some issues with using configfs in my module. The problem I ran
into could be solved if configfs_group_operations->drop_item() would
allow returning an error code. But I'll try to explain...

(1)
Say the user creates one object, let's say as objects/myobj1/. This
object is dependent on some (shared) parameters which the user created
under params/myparams1/. Now while myobj1/ is 'active', I don't want to
let the user remove myparams1/. I can prevent this by making the user
create a symlink(2) in the objects/myobj1/ directory to myparams1/, i.e.
objects/myobj1/params/ -> ../../params/myparams1/, to denote its use.
Now - if I have read the documentation correctly - the user cannot
remove myparams1/ without removing the params/ link first. So fine, so good.

(2)
Next the user may create several objects which may be dependent on
several params objects. Now I can solve this by creating a default group
for each object, i.e. on myobj1 creation there is objects/myobj1/params/
automatically. In that directory the user may create symlink(2)s to
several params/*/ dirs. Fine again.

(3)
Now what I want is the list of params an object uses to be an ordered
list. I cannot do this because there is no intrinsic order in a
filesystem. I can get the order by instead having an attribute called
param_list which contains the ordered list of all params to use, e.g.
> cat param_list
myparams2
myparams4
myparams1
However, this way I don't have any way to prevent the user from removing
params because configfs_group_operations->drop_item() is void and does
not allow me to return an error.

Question now: Do you think, ->drop_item() should be changed to allow
returning an error? If not, what do you think would be an appropriate
solution for the problem? (One solution would be that I trace back every
object that uses the params to get dropped, and delete the according
params entry from the object's params_list automatically... another
would be, that I keep a reference on each params used, so they are
deleted only from configfs but not from memory on removal, and rename
the list entries to <removed> or whatever... both ideas I don't like too
much.)

Thank you for any feedback!!!

PS: Please CC me on your replies, I'm not a LKML subscriber.
-
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-11 20:09    [W:0.026 / U:1.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site