From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 15:58:46 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 D366416A4CE; Thu, 5 Feb 2004 15:58:46 -0800 (PST) Received: from VARK.homeunix.com (adsl-68-122-2-18.dsl.pltn13.pacbell.net [68.122.2.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7ED0843D41; Thu, 5 Feb 2004 15:58:45 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: from VARK.homeunix.com (localhost [127.0.0.1]) by VARK.homeunix.com (8.12.10/8.12.10) with ESMTP id i15NwYmu046602; Thu, 5 Feb 2004 15:58:34 -0800 (PST) (envelope-from das@FreeBSD.ORG) Received: (from das@localhost) by VARK.homeunix.com (8.12.10/8.12.10/Submit) id i15NwXM7046601; Thu, 5 Feb 2004 15:58:33 -0800 (PST) (envelope-from das@FreeBSD.ORG) Date: Thu, 5 Feb 2004 15:58:33 -0800 From: David Schultz To: "M. Warner Losh" Message-ID: <20040205235833.GA2682@VARK.homeunix.com> Mail-Followup-To: "M. Warner Losh" , bde@zeta.org.au, jmallett@FreeBSD.ORG, ru@FreeBSD.ORG, current@FreeBSD.ORG References: <20040205091634.GC13932@FreeBSD.org.ua> <20040206012805.N8113@gamplex.bde.org> <20040205.075406.94840701.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040205.075406.94840701.imp@bsdimp.com> cc: jmallett@FreeBSD.ORG cc: ru@FreeBSD.ORG cc: current@FreeBSD.ORG Subject: Re: Very long SRCS list with unusually long src/ prefix 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: Thu, 05 Feb 2004 23:58:47 -0000 On Thu, Feb 05, 2004, M. Warner Losh wrote: > We also thought about just raising the limit in the kernel, but > quickly discovered that they were small to make exec more efficient. It should be possible to raise the limit without any performance impact in the normal exec path. The solution is to double the buffer size and retry in the case where exec() presently returns E2BIG, which only costs more when the argument list is very long. Even in this case, the cost of recopying the arguments should be less than the cost of forking an additional process. I looked into this a long time ago, but I abandoned the idea only because I wasn't sure that I understood all the possible ramifications of the ABI change for applications that make assumptions about ARG_MAX. Presumably if someone analyzed this problem carefully, the change could be made before 5.3-RELEASE.