From owner-freebsd-current@FreeBSD.ORG Sat Jun 26 22:31:42 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B73716A4CE for ; Sat, 26 Jun 2004 22:31:42 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C298143D48 for ; Sat, 26 Jun 2004 22:31:41 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i5QMVKaH063330; Sat, 26 Jun 2004 18:31:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5QMVKkS063327; Sat, 26 Jun 2004 18:31:20 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 26 Jun 2004 18:31:20 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Alex Keahan In-Reply-To: <200406262056.38279.alex@hightemplar.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: ibcs2 and svr4 compat headed for history X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jun 2004 22:31:42 -0000 On Sat, 26 Jun 2004, Alex Keahan wrote: > > The kernel's internal interfaces change; security bugs are discovered. > > Someone has to keep the code up to date, and the people who end up doing > > the work are *not* the people who advocate keeping the code around. > > That's a slippery slope and you don't want to go there. > > Maintenance of old code is the price you have to pay when you write new > code. That includes kernel interfaces and security bugs. Actually, Tim is not referring to security or other bugs that results from changes to the remainder of the code, rather, flaws that have existed in the svr4 code since inception. The svr4 code was apparently not written with an awareness of current concerns about buffer overflows, integer overflows, etc. Tim has invested a substantial amount of energy in trying to fix these issues in the svr4 code, but the reality is that regardless of any "bitrot" resulting from API changes inside the kernel, the svr4 code has serious bugs and issues, and no one owns the code. Many people would rather see Tim optimizing IPC performance, fixing bugs in mainstream code, finishing his multi-byte character support, etc. I don't really have a strong opinion on the removal of this code, since I don't use it or know anyone uses it, but I will say I agree with Tim's general observation that there are substantial volumes of code in the FreeBSD kernel that do impact our ability to introduce other new features, adapt to new platforms, perform performance optimization, etc. Any individual bit of such code can be maintained incrementally at low cost (and for us, cost means specifically volunteer developer time), but that as a whole, it does have a "weighing down" effect. The classic example of this is in our SMP work. One of the big impediments to forward progress in locking is that we do have a lot of "legacy" pieces of the system without owners who can perform the locking work. In the immediate short term we're going to hit a situation where we have to pick if we do or don't want Giant running over the network stack by default. If we opt to have it off by default, mainstream functionality will operate much faster, but subsystems unable to run without Giant will be broken. If we leave Giant on, then everything runs, but the mainstream bits will run slower. It's a boot-time selection right now, and works well in my development environment; the existence of the selection recognizes the trade-off. Eventually, I'm going to get to every piece of the stack and lock it down, but if the existence of edge case code that's not widely used causes us to defer permitting more mainstream code running faster, that's a trade-off we have to consider carefully. As with any commercial development organization, we have to make trade-offs about how we invest our resources -- it's a little harder, in fact, because I can't just tell people to work on things they don't want to work on. I have to convince them :-). This means that a slight pressure to remove under-maintained and unused or largely unused components will always exist, and sometimes doing so will make the overall work of the project much easier (or even possible). Someone will always disagree with the removal of any functionality or service; the hard thing to tell from a developer perspective is whether there are one or two people using it, or thousands. Sometimes someone will propose removing something and be overruled pretty quickly; other times, not so. The short answer, btw, is that if you (or someone you know) really cares about svr4, you'll need to identify someone to maintain it and bring it along. It might be an existing FreeBSD developer, or someone new. But it has to be someone who can show sustained interest in making it happen. > I just hope the removal of IBCS2 is not a political decision to get back > at SCO for their predatory legal tactics. I hardly think we'd be doing any damage to SCO by removing ABI compatibility with their system, and so any attempt to do so by this means would be pretty naive. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research