On Thu, 13 Jul 2000, Alan Cox wrote:
>
> This kind of lock shifting is a major upheaval. It invalidates any device
> driver testing done in the past weeks when we have been slowly moving towards
> more stability.
I much rather do it now than later. Later means either: (a) during 2.4.x
or (b) early in 2.5.x.
(a) is obviously impossiblme. 'Nuff said.
(b) means that we'll have these subtle incomptibilities between the
release kernel and the development kernel, and backporting of fixes etc
suddenly becomes much harder.
The (b) kind of inconsistency is unavoidable, but I'd rather avoid it for
the "mindless" kind of lock movement that affects a lot of drivers and
filesystems, yet is basically very simple ("mindless" != "easy").
Right now all the critical file_operations are without the kernel lock.
There's still stuff like "llseek" etc, but they're not used that much and
few filesystems/drivers need their own versions, so I think we can ignore
the ones that are left. We've reached the stage where the whole
open->read->write->close
sequence basically works without the kernel lock, and that is important.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jul 15 2000 - 21:00:17 EST