On Sun, 19 Nov 2006, Dmitry Torokhov wrote:
> I was actually looking at the driver core recently and was surprised that
> USB crapped all over it with its locking requirements. I don't think its a
> good idea to enforce one subsystem's lcoking rules onto everyone.
I agree. The only reason for doing it that way was I couldn't think of
any other approach.
> Would there be alot of objections if we add bus->[un]lock_device() and
> hide all uglies there? If methods are not set when bus is registered then
> standard dev->sem lock/unlock will be used.
That's a little too simple to work. You can see from examining the
existing code in bus.c and dd.c; there are places where the device needs
to be locked but not the parent, places where the parent needs to be
locked but not the device, and places where both need to be locked.
A slightly different way to accomplish much the same thing might be to
have a per-bus parent_needs_to_be_locked flag (or method). It wouldn't be
quite as elegant, though.
Alan Stern
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
