From owner-freebsd-current Fri May 4 1:46:28 2001 Delivered-To: freebsd-current@freebsd.org Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by hub.freebsd.org (Postfix) with ESMTP id D1C9337B423 for ; Fri, 4 May 2001 01:46:24 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from mindspring.com (pool0075.cvx7-bradley.dialup.earthlink.net [209.178.164.75]) by hall.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id EAA20675; Fri, 4 May 2001 04:46:20 -0400 (EDT) Message-ID: <3AF26C70.B8470992@mindspring.com> Date: Fri, 04 May 2001 01:46:40 -0700 From: Terry Lambert Reply-To: tlambert2@mindspring.com X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joerg Wunsch Cc: freebsd-current@FreeBSD.ORG Subject: Re: Any chance of release patch being committed? References: <200105032055.NAA01895@usr05.primenet.com> <200105032200.f43M0wD89227@uriah.heep.sax.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG J Wunsch wrote: > Terry Lambert wrote: > > > Isn't anyone but me and Walnut Creek cum BSDI cum Windriver > > Systems using "make release"?!? > > We are, but why would we use anything else than GENERIC for it, > seriously? I'd never roll a `release' for my current machine. Examples abound: 1) Licensed commercial drivers not present in GENERIC 2) Cut down kernel for low memory systems 3) Kernel without support for 686/586/386 in an embedded system 4) Kernel without most of the disk controllers, e.g. a Compaq-specific "Jump Start" disk for FreeBSD Etc. It shouldn't matter anyway; it doesn't change the normal default sysinstall behaviour, image, or image size at all (the image is identical), unless KERNCONF is overridden. If that's so unreasonable, I suggest you remove the "?" before the "=" in /usr/src/release/Makefile in the KERNCONF assignment, which looks like: KERNCONF?=GENERIC Since it makes damn little sense to allow it to be overridden, if the resulting CDROM will fail to install /kernel, and the resulting system will not be able to boot without an explict "load kernel.MYKERNEL" command to the boot loader. Doing that would reduce functionality; making my change would increase it... but make one or the other of them, please: in it's current state, the code _pretends_ that an override will work, when it will not. I hate code that lies to me, even if by omission; don't you? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message