This is a discussion on configfs issues - Linux ; Hi all, [since I didn't get any replies on LKML maybe somebody is willing to give some comments in this group...] I've got some issues with using configfs in my module. The problem I ran into could be solved if ...
[since I didn't get any replies on LKML maybe somebody is willing to
give some comments in this group...]
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...
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.
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.
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
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
or whatever... both ideas I don't like too
Thank you for any and every feedback!!!