Joe Thornber wrote:
On Mon, Dec 08, 2003 at 11:15:20PM -0800, Mike Christie wrote:
If you look at the attached patch (dm-kobj.patch) built and tested against
test10-dm1 you will see kobjects used as a replacement for the "atomic_t
holders" value in dm_table and mapped_device. There is no sysfs :)
md_ktype.sysfs_ops ?
The kobject_add call is what creates the sysfs files and dirs. This
seperation is what allows you to use kobjects for different things like
refcounting, sysfs, obj lists. If I have a accessor function, in the
sysfs interface code I can set the ops when I do a kobject_add. I was
thinking that the accessor might still count as uglying up the table
abstraction too.
and I did not modify any of the get/put semantics. The only change
is the kobject infrastructure manages the ref count and calls the
release function when the count goes to zero.
ok, so your patch does the same as the current code in a slightly more
verbose way ?
yeah.
With this patch, I can use the callback method, the sysfs junk will not be
coupled to the core code, no abstractions are broken and we will all use
the same ref count. Better?
I don't think I really see why you must have the reference counting
done with kobjects rather than the current method.
When a user opens a sysfs file the kobject ref count is incremented in
fs/sysfs code, so if at the same time someone were to do a device remove
command it is not actually going to be freed until the file is released
and the ref count decremented.
So it's really just a matter of having two ref count systems vs one.
Remember I'm also maintaining a 2.4 version of dm, and need a really
good reason to have the implementationsh diverge.
all I have is the sysfs coding police telling me to put the kobjects in
the core structs becuase the two ref count approach could be a little
akward.
mike
