Date: Fri, 09 Jul 1999 12:36:47 +0200 From: Marc van Kempen <marc@bowtie.nl> To: Gregory Sutter <gsutter@pobox.com> Cc: Matthew Dillon <dillon@apollo.backplane.com>, freebsd-smp@FreeBSD.ORG Subject: Re: SMP comparisons Message-ID: <199907091036.MAA03701@bowtie.nl> In-Reply-To: gsutter's message of Fri, 09 Jul 1999 02:46:36 -0700. <19990709024636.R13537@001101.zer0.org>
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. > I wholeheartedly agree, I must say I don't understand -core in this respect either. Sure I can understand that people feel threatened (or feel the stability of the system is threatened) by someone going through the code with the energy that Matt has displayed, especially when the code is so complicated and fragile, and a good review process should be in place. On the other hand doing nothing about it will only result in FreeBSD falling behind with respect to new developments and drive away talented *and* willing developers, and surely that is somehting worth the time and attention of -core, or so one would hope! Regards, Marc. ---------------------------------------------------- Marc van Kempen BowTie Technology Email: marc@bowtie.nl WWW & Databases tel. +31 40 2 43 20 65 fax. +31 40 2 44 21 86 http://www.bowtie.nl ---------------------------------------------------- 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?199907091036.MAA03701>