Date: Tue, 20 Jun 2000 12:54:06 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Warner Losh <imp@village.org> Cc: Poul-Henning Kamp <phk@critter.freebsd.dk>, mjacob@feral.com, freebsd-smp@FreeBSD.ORG Subject: Re: SMP discussion moving to freebsd-smp Message-ID: <200006201954.MAA88510@apollo.backplane.com> References: <55142.961529404@critter.freebsd.dk> <200006201936.NAA71564@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200006201954.MAA88510>