Messages in this thread | | | Subject | Re: [PATCH 1/19] MUTEX: Introduce simple mutex implementation | From | Arjan van de Ven <> | Date | Wed, 14 Dec 2005 12:42:00 +0100 |
| |
On Wed, 2005-12-14 at 11:24 +0000, Alan Cox wrote: > On Mer, 2005-12-14 at 12:08 +0100, Arjan van de Ven wrote: > > 1) the BKL change hasn't finished, and we're 5 years down the line. API > > changes done gradual tend to take forever in practice, esp if there's no > > "compile" incentive for people to fix things. > > This isn't a "fix" however, its merely a performance tweak.
it's a conceptual API split that, if nothing else, declares intent and usage pattern more specifically. Performance is just one of the angles. Other angles are that it's possible to treat mutex users different (like Ingo is doing in -rt, where you can temporary boost a mutex owner if the mutex gets contended, other uses are better hold time metrics etc etc)
> Drivers > using the old API are not a problem because > > a) The old API is needed long term for true counting sem users
this is skipping one bridge ;) A counting semaphore is needed long term. API is up for debate in the sense that it's not clear that a non-compile-time thing is the right solution.
> Thats rather different to the BKL
BKL is different in that it's more work to do a conversion (eg the BKL semantics are rather complex compared to normal spinlock / semaphore / mutex semantics). So yes BKL is harder, and not really possible to do in one go. Unlike these... For BKL there was no choice. Here there is.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |