HEADSUP: KSE about to become a kernel option

If you use a GENERIC kernel, then this change won't affect you
because the KSE option will be on by default in GENERIC on
all arches/machines except sun4v (which doesn't handle signals
properly with the KSE code in the kernel).

If you use a custom kernel, you need to add 'options KSE' to
your kernel config to continue to use libpthread.

If you use libmap to map libpthread.so.2 to libthr.so.2, then
you can use a kernel with or without 'options KSE'.

KSE has been declared as a kernel option in src/sys/conf/options
for a while now, so even though I haven't committed any files
which use it, you can add it to your kernel config right now
so that you are ready for when the cvs changes make their way
out to the cvsup mirrors.

I am planning on getting DTrace into current by the end of this
year and one of the first things I want to use it for is to
measure the differences between libpthread and libthr to see
where we suck compared to Linux and Solaris. To date people
have anecdotal tales to tell about one being better than the
other, but we haven't had a good way to measure exactly what it
is that is causing the poor relative performance.

With this change, it is possible to build a GENERIC kernel
(with KSE support) and a !KSE kernel and alternately boot between
the two while using the exact same installed ports of your
favourite threaded applications.

Hopefully, if you care about threaded performance in FreeBSD,
you will be prepared to help run DTrace (when it becomes
available) on _your_ system the way _you_ like it to measure
which thread implementation is better for _you_.

Out of this I hope to determine which thread implementation
deserves to be the default, and possibly conclude that one
thread implementation doesn't stand up in comparison with
Linux and Solaris.

I also hope to get enough info to write a paper about the use
of DTrace in FreeBSD, possibly for BSDcan 2007.

I realise that the source changes to make KSE a kernel option
will offend some people because they are essentially a lot
of #ifdefs. This is deliberate because it shows what code
would remain if KSE support was to be ripped from the kernel.
Yes, the code will be more complex to maintain.

--
John Birrell
(with flame suit on)