lkml.org 
[lkml]   [2010]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 8/19]: SCST SYSFS interface implementation
On 11/09/2010 10:06 PM, Vladislav Bolkhovitin wrote:
>
> Sorry, but what is incorrect in the working implementation without any
> bugs doing its job in the simplest, smallest and clearest way?
>
> If those objects remade to free themselves in the kobjects release(),
> what value would it add to them? Would the implementation be simpler,
> smaller or clearer? Not, I believe, new implementation would be only
> bigger and less clear. So, what's the point to do it to make the code worse?
>

Totally theoretically speaking, since I have not inspected the code.

If today you wait for the count to reach zero, then unregister
and send an event to some other subsystem to free the object.

Is it not the same as if you take an extra refcount, unregister and
send the event at count=1. Then at that other place decrement the last
count to cause the object to be freed.

I agree that it is hard to do lockless. what some places do is have
an extra kref. The kobj has a single ref on it. everything takes the
other kref. when that reaches zero the unregister and event fires
and at free you decrement the only kobj ref to deallocate. This is one
way. In some situations you can manage with a single counter it all
depends.

Boaz


\
 
 \ /
  Last update: 2010-11-10 11:01    [W:0.164 / U:2.380 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site