Date: Mon, 25 Sep 1995 11:59:33 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: wollman@lcs.mit.edu (Garrett A. Wollman) Cc: terry@lambert.org, current@freebsd.org Subject: Re: kernel versions and config's rm -rf Message-ID: <199509251859.LAA05603@phaeton.artisoft.com> In-Reply-To: <9509251502.AA12642@halloran-eldar.lcs.mit.edu> from "Garrett A. Wollman" at Sep 25, 95 11:02:32 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509251859.LAA05603>