Re: [PATCH driver-core-next] sysfs: rename sysfs_assoc_lock and explain what it's about

[Tejun Heo <tj@kernel.org>]

Hello, Eric.

On Wed, Oct 30, 2013 at 03:29:38PM -0700, Eric W. Biederman wrote:
> Except every time sysfs exports a restriction like that and doesn't
> verify people have held up their end of it someone in the kernel
> inevitably gets the code wrong.  So I don't see how a big fat comment
> buried deep in the underlying abstractions that people use is going to
> make the code easier to understand or maintain.  It certainly won't
> prevent people from goofing up and with no warning.

The big fat comment is not meant for kobject users.  They have always
assumed the responsibility of not issuing conflicting operations
concurrently.  The comment explains the role of the lock so that a
person reading the code can understand what's going on as it is
confusing why the locking is necessary there when the caller is
supposed to be responsible.

Now, it's true that we *can* make kobject interface to allow multiple
concurrent operations and synchronize internally by generalizing the
locking.  Given how kobject is used, I'm not sure what that'd buy tho,
especially for removal.  Because removal puts the base ref as I wrote
before, it's an operation intrinsically reserved to the owner of the
object.  I'm pretty skeptical about its usefulness but if you think
it's worthwhile, please feel free to give it a shot.

Thanks.

-- 
tejun