[dm-devel] [PATCH][RESEND+fixes] dm + sysfs
Mike Christie
mikenc at us.ibm.com
Tue Dec 9 06:01:01 UTC 2003
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
More information about the dm-devel
mailing list