Messages in this thread | | | Date | Thu, 31 Oct 2013 13:11:20 -0400 | From | Tejun Heo <> | Subject | Re: [PATCH driver-core-next] sysfs: rename sysfs_assoc_lock and explain what it's about |
| |
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
| |