[dm-devel] [PATCH][RESEND+fixes] dm + sysfs

[Mike Christie]

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