From owner-freebsd-hackers Thu Nov 9 18:46:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id SAA25379 for hackers-outgoing; Thu, 9 Nov 1995 18:46:50 -0800 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 SAA25316 ; Thu, 9 Nov 1995 18:45:24 -0800 Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id TAA02607; Thu, 9 Nov 1995 19:40:51 -0700 From: Terry Lambert Message-Id: <199511100240.TAA02607@phaeton.artisoft.com> Subject: Re: config, other kernel build tools To: rkw@dataplex.net (Richard Wackerbarth) Date: Thu, 9 Nov 1995 19:40:51 -0700 (MST) Cc: terry@lambert.org, current@freebsd.org, hackers@freebsd.org In-Reply-To: from "Richard Wackerbarth" at Nov 9, 95 07:53:35 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1545 Sender: owner-hackers@freebsd.org Precedence: bulk > And they don't belong in the kernel either. They are NOT a part of the > kernel, they are a TOOL. So put them in the tools directory associated with > the build in progress. That describes boot, netboot, fbsdboot (which is a *DOS* program!). I think config has about as much association with a particular kernel as /sys/kern/vnode_if.sh. Which is to say, there is a 1:1 correspondence with potential kernel changes. > To me that means that they belong in usr/?bin. (I'm not sure what the > distinction between bin and sbin should really be. These are uncommon > commands, but still commands on the same level as troff. I tend to say > usr/bin.) But config isn't a command, it's a kernel configuration semantics parsing tool to make a buildable directory in compile and add a whole bunch of crap that should be dynamically initialized anyway. It's as much a part of the kernel as the other pieces I mentioned. > Notice that I did NOT say /usr/bin. Each build should have its own set of > tools. Definitely -- and they should be associated with the source in some way. Like putting them in a "tools" dir at the same level as the kern and compile and arch specific directories. > Otherwise the proper compilation of the tool for the purpose of the > particular build must be used. Right. But I can't use it because using it entails murdering the one for the current system (ie: installing it). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.