From owner-freebsd-current@FreeBSD.ORG Sun Jun 27 15:23:59 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 AC03A16A4CE for ; Sun, 27 Jun 2004 15:23:59 +0000 (GMT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ED6C43D1D for ; Sun, 27 Jun 2004 15:23:59 +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 i5RFNiaH074315; Sun, 27 Jun 2004 11:23:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i5RFNihQ074312; Sun, 27 Jun 2004 11:23:44 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sun, 27 Jun 2004 11:23:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: "Cordula's Web" In-Reply-To: <20040627080705.1CE964AC84@fw.farid-hajji.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-current@freebsd.org cc: alex@hightemplar.com 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: Sun, 27 Jun 2004 15:23:59 -0000 On Sun, 27 Jun 2004, Cordula's Web wrote: > I do use Maple V/Solaris x86 (but under CURRENT only in text mode) with > the svr4 emulation. It was not really easy to find all libs and fiddle > with the loader, but it works, at least on my copy. > > However, if the mere presence of svr4 in the 5.x kernel slows other > important development down, then it is a good and valid reason to axe > it. I have other ways to run this and no more objections. > > Thanks for clarifying the reasons behind this decision. Well, I don't know if I would call what I wrote reasons behind this decision, so much as a justification and context for intermittent removal of functionality from the tree. As I said, I don't really have an opinion specifically on the svr4 compatibility code, as much as on how we structure the project. The primary complaint about the svr4 and ibcs2 code is that they are both large pieces of code undergoing minimal "maintenance" -- that is to say, incremental bug fixing and cleanup by a party willing to claim responsibility for the subsystem. In contrast, we have less frequently used subsystems which do see active maintenance (MAC Framework being one), and there seems not to be too much discussion of removing them. So the key to having functionality live on in the presence of widespread change in the tree is having a willing and credible maintainer; if you know of someone willing to do this, that would probably make a big difference :-). While the axes in the project may well have their way on this one, it's worth keeping in mind that there will be more discussion of it than just by said axes. The release engineering team, for example, will certainly have something to say on the topic. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Principal Research Scientist, McAfee Research