configfs issues

[Michael Noisternig]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/