Date: Fri, 9 Jul 1999 02:46:36 -0700 From: Gregory Sutter <gsutter@pobox.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: SMP comparisons Message-ID: <19990709024636.R13537@001101.zer0.org> In-Reply-To: <199907081721.KAA41309@apollo.backplane.com>; from Matthew Dillon on Thu, Jul 08, 1999 at 10:21:17AM -0700 References: <199907081712.NAA20677@cs.rpi.edu> <199907081721.KAA41309@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jul 08, 1999 at 10:21:17AM -0700, Matthew Dillon wrote: > > The work on the VFS/BIO subsystem, even with Kirk helping, is going > to go slowly no matter what, but it will running worst case without > commit privs for me. I've already fallen way behind on tracking down > the remaining NFS problems and the VM/mmap problems because of time > constraints which are not made better by core's unenlightened stance. > > In order to make real progress on any of these things current is > really going to have to become a development kernel again instead > of an 'must always be working' kernel. Like the VM adjustments > I made earlier in the year, there are certain pieces of the VFS/BIO > subsystem that are going to have to be ripped to shreads later this > year before it can be put back together. I think some of the upcoming > SMP issues are going to the same: Matt, I, as well as several others I've spoken to, am also eager to see you regain your commit privileges. In fact, since USENIX, where I fully expected things to be hashed out so that you _would_ regain them, I've really become discouraged with the opacity and apparent sluggishness of the core team on this issue. I've recently seen you do some excellent design work on subsystems that few have cared to or possessed the ability to work on. I hardly think that you should still be forced to deal with the aftereffects of a situation that should have been over and dealt with long ago. WRT the -CURRENT issue, I also am in agreement with you on that. -CURRENT is a development environment and those who run it must understand that it sometimes may break -- that's the nature of development environments. I would not, at this time, like to see a third branch become necessary (in the form of an -ALPHA or -DEVEL), as I don't think that there is the manpower to care for the release structure of a -DEVEL as well as -CURRENT and -STABLE. There are a lot of big issues that FreeBSD has to confront within the next year, and without some of this major design work, and accompanying breakage, we're going to lose to operating systems that can do SMP and have kernel thread support, among other things. Greg -- Gregory S. Sutter "Software is like sex; it's better mailto:gsutter@pobox.com when it's free." -- Linus Torvalds http://www.pobox.com/~gsutter/ PGP DSS public key 0x40AE3052 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?19990709024636.R13537>