From owner-freebsd-current@FreeBSD.ORG Fri Feb 6 01:22:31 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 7FC3316A4CE for ; Fri, 6 Feb 2004 01:22:31 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4D1643D45 for ; Fri, 6 Feb 2004 01:22:27 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.40.88) by smtp01.syd.iprimus.net.au (7.0.024) id 400C4DF400733168; Fri, 6 Feb 2004 20:23:44 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id F105041AE; Fri, 6 Feb 2004 20:22:08 +1100 (EST) Date: Fri, 6 Feb 2004 20:22:08 +1100 From: Tim Robbins To: Julian Elischer Message-ID: <20040206092208.GA52274@cat.robbins.dropbear.id.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: FreeBSD current users Subject: Re: FreeBSD 1.1 under -current :-) 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: Fri, 06 Feb 2004 09:22:31 -0000 On Fri, Feb 06, 2004 at 12:37:30AM -0800, Julian Elischer wrote: [...] > apparrently programs in 1.1 can not handle that the PID can go past > 32767 now.. 'wait()' for example fails.. > > ok , so recompile my kenrel with PID_MAX set to 30000 > and try again.. > all works fine.. > > I'm tempted to make PID_MAX a tunable or a sysctl.. I think FreeBSD 1.1 compatibility is obscure enough that there's no need for it to work in out of the box (i.e. GENERIC) at the cost of increased complexity in non-obscure configurations. Ideally, COMPAT_43 would be broken up into COMPAT_43, COMPAT_FREEBSD[123], etc., removed from GENERIC and perhaps then we could define PID_MAX conditionally on these options or at least #error out. > I think that some compatibility modes may have teh same problems > (though I doubt that many people use anything other than Linux > compatibility) As far as I know, only iBCS2 needs 16-bit bits. iBCS2 support would be more productive dead, as would our obviously unused and untested SVR4 support. Tim