From owner-freebsd-smp Tue Jun 20 13:10:57 2000 Delivered-To: freebsd-smp@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id F17ED37BFA6 for ; Tue, 20 Jun 2000 13:10:48 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA41798; Tue, 20 Jun 2000 14:10:35 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA72038; Tue, 20 Jun 2000 14:09:05 -0600 (MDT) Message-Id: <200006202009.OAA72038@harmony.village.org> To: Matthew Dillon Subject: Re: SMP discussion moving to freebsd-smp Cc: Poul-Henning Kamp , mjacob@feral.com, freebsd-smp@FreeBSD.ORG In-reply-to: Your message of "Tue, 20 Jun 2000 12:54:06 PDT." <200006201954.MAA88510@apollo.backplane.com> References: <200006201954.MAA88510@apollo.backplane.com> <55142.961529404@critter.freebsd.dk> <200006201936.NAA71564@harmony.village.org> Date: Tue, 20 Jun 2000 14:09:05 -0600 From: Warner Losh Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200006201954.MAA88510@apollo.backplane.com> Matthew Dillon writes: : 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! OK. That's useful to know. I just need that much of the system to work for my work on NEWCARD. Well, it would be really nice if loadable modules don't get broken in all of that, but I know that part of the system will go through its unstable phase like everything else. : 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. That will hit NEWCARD, as an example :-). However, I view it as my responsibilty to cope with such changes and to assist as much as I can in moving forward. It may have some minorly negative implications, but nothing to get upset about. OK. So long as there's a strong commitment to having a "-current-ly" stable core part of the kernel, I can live with the pain of instability around the edges. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message