From owner-freebsd-current Mon Sep 25 12:02:47 1995 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id MAA19429 for current-outgoing; Mon, 25 Sep 1995 12:02:47 -0700 Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id MAA19424 for ; Mon, 25 Sep 1995 12:02:41 -0700 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id LAA05603; Mon, 25 Sep 1995 11:59:33 -0700 From: Terry Lambert Message-Id: <199509251859.LAA05603@phaeton.artisoft.com> Subject: Re: kernel versions and config's rm -rf To: wollman@lcs.mit.edu (Garrett A. Wollman) Date: Mon, 25 Sep 1995 11:59:33 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org In-Reply-To: <9509251502.AA12642@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Sep 25, 95 11:02:32 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1616 Sender: owner-current@freebsd.org Precedence: bulk > > The reason for this behaviour in the first place was an issue of > > dependencies not being calculated correctly > > There is nothing wrong with the way the dependencies are calculated, > and has not been in a long time. The reason for that behavior is > because Jordan got tired of dealing with people who didn't clean their > kernels after changing options that have a major impact on the > generated code, then building broken kernels and calling WC to > complain. This is the way all dependencies in any program have worked > since the dawn of time, and the appropriate solution is not to > kludge up the config program but to eliminate compilation options as > user-serviceable parts. With due respect, you have just identified a dependency between options and object module content that should cause the object module affected to be rebuilt when the options changed. Yet this dependency is not enforced. The current workaround to this failure in the dependency graph closure is "make clean". But make no mistake: this is not a "fix", it is a "workaround". *ONLY* the affected modules should have been rebuilt. The number of PTY's is one example of a compile time option that the resulting code depends upon. Making PTY's dymanically allocated with a soft limit alterable by root via sysconfig is the soloution to this particular problem. This is similar to the solution for RFC extentions to TCP/IP and IP forwarding which recently went into the code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.