David Howells wrote:
Alan Cox <[email protected]> wrote:
It seems to me it would be far far saner to define something like
sleep_lock(&foo)
sleep_unlock(&foo)
sleep_trylock(&foo)
Which would be a _lot_ more work. It would involve about ten times as many
changes, I think, and thus be more prone to errors.
"lots of work" has never been a valid reason for not doing a kernel
change...
In this case, introducing a new API means the changes can be made over time.
As time goes on you can convert more and more code to the mutex/sleep
lock and any tricky code just stays with the older API until someone who
understands it can vet it.
As Alan mentioned, the standard counting semaphore API is up/down.
Making those refer to a sleeping mutex violates the principle of least
surprise.
Chris
-
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]
