The kernel will always be buildable. It should be stable enough to last for 5 minutes. But there are going to be a lot of legacy issues that need to be fixed -- drivers that get broken. What will probably happen is that a base system with only core features enabled (disk, serial, console, network) will always be more stable during the mergework then a system with the kitchen sink in. A system with the kitchen sink in may not even compile!

I don't expect the work required to make drivers compile and run again to be all that difficult, that's the whole reason for keeping the SPL compatibility code in place during the merge work. But it will also be non-zero, and we will want the SPL compatibility code *gone* by release time.

I'll give you one example of this: Drivers that create kernel threads (there are two or three) have to use the new mutex code on entry now, and the kthread_create() has been renamed to mp_kthread_create() to guarentee that. Fixing them will not be difficult, but is also non-zero.

Another example: cpu_switch() has been renamed to mp_cpu_switch() and mi_switch() has been renamed to mp_switch(). These interfaces may now only be called from mutex-aware code. I've adjusted all the core code to deal with it but there are probably a few drivers that try to poke too deep into the kernel that need to be adjusted as well. The adjustments required are straightforward. For example, in order to be able to call mp_switch() the caller must hold the scheduler mutex and release Giant (there are two helper routines to do all the dirty work here).

-Matt

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message