From owner-freebsd-stable@freebsd.org Tue Dec 13 04:22:43 2016 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8CB19C7428C for ; Tue, 13 Dec 2016 04:22:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 44FCA1462 for ; Tue, 13 Dec 2016 04:22:43 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ua0-x229.google.com with SMTP id 20so101901128uak.0 for ; Mon, 12 Dec 2016 20:22:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mj16ViS/rPF5dPRDBfqisujvfO2QLox5EVRK7Wh1vVU=; b=MEiv0vhXbnq9Ng38rBmM8DrA79YRPnDltV1autJe9zvqzFSzazy1SVu/+JTeC1qDu0 /1cXAW+amikPjqbU8R8EQZCPmmVkj0gFM1+nX4p3EArwljrC9F3tfpf1BIkwOeQWBkqk YJYV6aiMdKUhLbyj15cs5F1G17Ea8V76B+JQDqnJ3msw3zLMNy56SL5TB9v/MB9TzVds 9Ctecet3va6SeoEIY/OyHV+xLBAWfOw3lgOSzFR3QmlsxuAlPzd2rK3ZCsfQ8gQHDTNF yqf2LCdPPDgy/MCkYA4xDzxCiifMUn6OPigZAMrYRACdv7Nqj9CBM31v3CO2OaYB+q+R y25w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mj16ViS/rPF5dPRDBfqisujvfO2QLox5EVRK7Wh1vVU=; b=NszcF1bYfuPXme+SrjCfomdYgpiJdoF7xV+ZSp9Pn21NovwUB6bJ8E8i3wQpWZloWf zkOBMRdpBVihy9wry8erKRhShAGtxUhrvUwCQXx2A80MTdv274g8y1FqZQpPrne8to8H owL2bOIQWGtrQybJ+FjadnrhfkUOn9twT2ww9C6g/phRO+s6pnW294NGCcdseXDpyoNG CfLnEqvmPf8ENoI8S1syRHenYTekkdtinMBIvbW1PRpFvLRi+sU1UrVN/PYxgOLU2aUH /OYZGdNgg2y5d4AiUf6/fe/nRpVfdDUH8vww1X/OrNl0YYT8usuExo75pXPynrehdx/a lVFw== X-Gm-Message-State: AKaTC02LRJ28DXgWm9eg3lBHJP4YPKp5dpK3bOPu2WD/U5VtfzJOm/s9VIm6St6MvcPqKGr+TuG/mZ7EJY6QDA== X-Received: by 10.176.64.234 with SMTP id i97mr65578684uad.7.1481602962289; Mon, 12 Dec 2016 20:22:42 -0800 (PST) MIME-Version: 1.0 Sender: kob6558@gmail.com Received: by 10.103.106.66 with HTTP; Mon, 12 Dec 2016 20:22:41 -0800 (PST) In-Reply-To: <86pokwptmd.wl-herbert@mailbox.org> References: <201612120138.uBC1cA59025994@sdf.org> <86r35dd46x.wl-herbert@mailbox.org> <9B.7B.16304.3F86E485@dnvrco-omsmta02> <15672f53-1a34-3120-0aa8-03aa6401be54@zyxst.net> <86pokwptmd.wl-herbert@mailbox.org> From: Kevin Oberman Date: Mon, 12 Dec 2016 20:22:41 -0800 X-Google-Sender-Auth: b-5-6Xk28DbLyC8ZrBSJWyRieXo Message-ID: Subject: Re: make buildkernel does not respect KERNCONF or JOBS in /etc/make.conf To: "Herbert J. Skuhra" Cc: FreeBSD-STABLE Mailing List Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 04:22:43 -0000 On Mon, Dec 12, 2016 at 4:20 PM, Herbert J. Skuhra wrote: > Kevin Oberman skrev: > > > > Clearly the documentation is a bit behind the times. For some time people > > have used KERNCONF to build multiple kernels, but that was a lucky things > > that was not officially supported. It just happened to work. Then, with > > 11.0, it no longer did in many cases sue to changes in the kernel build > > system. When people complained, there did not seem to be a way to fix > this > > without blocking future goals in speeding up and enhancinghte standard > > kernel build. > > > > The result was BUILDKERNELS. It was specifically designed to allow the > > building of multiple kernels and the appropriate modules. This would > always > > take longer and use more disk space, but it would work reliably. Now, bit > > building a single, local kernel, KERNCONF is the best way, though I > suspect > > that it make only a small difference until new capabilities are added > later > > in the life of 11. > > > > So, while it seems the man pages need to catch up, building multiple > > kernels should be done with KERNCONF in either make.conf or src.conf and > > multiple kernels with BUILDKERNELS. > > > > This is from my recollection of the discussion thread. I'll admit to > being > > too lazy to go find and read all of it. I suspect it was on current@, > but > > I'm not even sure of that. > > ??? > > From /usr/src/Makefile.inc1: > > 1137 .if ${TARGET_ARCH} == "powerpc64" > 1138 KERNCONF?= GENERIC64 > 1139 .else > 1140 KERNCONF?= GENERIC > 1141 .endif > [...] > 1149 BUILDKERNELS= > 1150 INSTALLKERNEL= > 1151 .if defined(NO_INSTALLKERNEL) > 1152 # All of the BUILDKERNELS loops start at index 1. > 1153 BUILDKERNELS+= dummy > 1154 .endif > 1155 .for _kernel in ${KERNCONF} > 1156 .if exists(${KERNCONFDIR}/${_kernel}) > 1157 BUILDKERNELS+= ${_kernel} > 1158 .if empty(INSTALLKERNEL) && !defined(NO_INSTALLKERNEL) > 1159 INSTALLKERNEL= ${_kernel} > 1160 .endif > 1161 .endif > 1162 .endfor > > So setting BUILDKERNELS has no effect. > > -- > Herbert > I think you miss the significance. BUILDKERNELS only is used to build the kernels. It is not used by installkernel as installing two kernels does not make sense. It is ONLY used to build multiple kernels. KERNCONF is still used to specify the kernel, with attendant modules, to be installed. I should also mention that, if you want to install a new kernel without overwriting the old kernel and modules (/boot/kernel.old/), "make reinstallkernel". It replaces the existing kernel instead of renaming the kernel directory to kernel.old. I find this very handy, but it is poorly documented. So, if you want to install GENERIC and not lose your last working kernel, "make reinstallkernel KERNCONF=GENERIC". That will blow away the bad kernel and modules and install GENERIC. Note that it does not touch the /usr/obj directory that PUMPKIN is built in, so PUMPKIN and similarly be reinstalled. The man page for src.conf is automatically generated and only lists those values which are specific to src.conf (WITH_ and WITHOUT_) and describes its use. It is used as input for system builds and installs but should not be accessed for any other purpose. make.conf is always read by make with no regard to what is being made. (N.B. I believe that some people have ignored this in some ports stuff.) Anything that is put into make.conf may be placed in src,conf if you only want to have it used when building/installing the kernel and world. I'm probably forgetting something, but I hope this explains it a bit. -- Kevin Oberman, Retired Network Engineer and kid herder