User: Password:
|
|
Subscribe / Log in / New account

Might 2.6.35 be BKL-free?

Might 2.6.35 be BKL-free?

Posted Apr 30, 2010 2:37 UTC (Fri) by RogerOdle (subscriber, #60791)
Parent article: Might 2.6.35 be BKL-free?

Why keep something around that is not really wanted? That only invites developers to periodically introduce new dependencies. You will eliminate in one release only to have to put it back in later.

It might be desirable to have an init option to enable or disable the BKL. It could make testing easier and faster.


(Log in to post comments)

Might 2.6.35 be BKL-free?

Posted May 1, 2010 1:42 UTC (Sat) by chantecode (subscriber, #54535) [Link]

>> Why keep something around that is not really wanted?

Because it might protect datas from concurrent accesses.

>> That only invites developers to periodically introduce new dependencies. >> You will eliminate in one release only to have to put it back in later

Not really. Most of the time, a new driver that uses the bkl will be spotted
and won't be merged, except may be for the llseek case, which is a bit particular.

>> It might be desirable to have an init option to enable or disable the BKL. It could make testing easier and faster.

The problem is not here. You don't catch every possible races by just testing without the bkl. When you kill the bkl at some places, you need to prove that what you are doing is safe, by explaining the locking involved and so. Testing is not sufficient.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds