On Sun, Apr 13, 2008 at 9:08 AM, Ingo Molnar <mingo@elte.hu> wrote:
quoted text
>
>  but semaphores will be _removed_, _completely_. Rewriting them in
>  generic C code is just the first step towards that - it consolidates all
>  the myriads of semaphore implementations that Linux has spread out.
>
>  your proposed change to change completions to semaphores is totally
>  backwards and prolongs an API we want to get rid of. Did you miss this
>  aspect of the mutex rewrite, of the semaphore-to-mutex,
>  semaphore-to-completions and semaphore-to-rwsem conversions?

I know the semaphore-to-mutex rewrites were essential a.o. to make
further merging of the real-time tree into the mainstream Linux kernel
possible. But the semaphore concept is more powerful than the mutex
concept: semaphores can be used to let one thread wait for a state
change reported by another thread. Should all state-change-waiting be
implemented via wait_event*() functions ?

One of the strengths of the Linux kernel is that the barrier for new
developers is low: in theory anyone familiar with the C programming
language can start writing kernel drivers. Most people still learn
kernel development via the third edition of the "Linux Device Drivers"
book, and with some luck or some help, they come across an overview of
the 2.6 kernel API changes (http://lwn.net/Articles/2.6-kernel-api/).
The LWN book is getting outdated after all the 2.6 kernel API changes,
and the page with 2.6 kernel API changes was last updated six months
ago. Where can a kernel developer find up to date information about
kernel programming ?

Bart.
--
unsubscribe notice
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/