From owner-freebsd-arch@FreeBSD.ORG Fri Oct 29 01:57:26 2010 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 48F1710656B4; Fri, 29 Oct 2010 01:57:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id EE96A8FC0C; Fri, 29 Oct 2010 01:57:25 +0000 (UTC) Received: from [10.0.0.182] (182.imp.bsdimp.com [10.0.0.182] (may be forged)) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o9T1qbBK035890; Thu, 28 Oct 2010 19:52:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Message-ID: <4CCA28E5.6020102@bsdimp.com> Date: Thu, 28 Oct 2010 19:52:37 -0600 From: Warner Losh User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.9) Gecko/20100918 Thunderbird/3.1.4 MIME-Version: 1.0 To: John Baldwin References: <201010271355.40685.jhb@freebsd.org> <201010281249.37512.jhb@freebsd.org> <4CC9B3A7.60701@bsdimp.com> <201010281401.33549.jhb@freebsd.org> In-Reply-To: <201010281401.33549.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, imp@FreeBSD.org, TAKAHASHI Yoshihiro , freebsd-arch@FreeBSD.org Subject: Re: [PATCH] Headers for the x86 subtree X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 01:57:26 -0000 On 10/28/2010 12:01, John Baldwin wrote: > On Thursday, October 28, 2010 1:32:23 pm Warner Losh wrote: >> On 10/28/2010 10:49, John Baldwin wrote: >>> On Thursday, October 28, 2010 11:58:25 am Warner Losh wrote: >>>> On 10/28/2010 08:53, TAKAHASHI Yoshihiro wrote: >>>>> In article<201010281013.03261.jhb@freebsd.org> >>>>> John Baldwin writes: >>>>> >>>>>> I'm still doing testing, but this seems to be working so far. I am >>>>>> moving mca.h as my current test. >>>>> sys/conf/kmod.mk requires the same change of sys/conf/kern.post.mk. >>>> I think that the pre-patch kern.post.mk code actually may be wrong... >>>> Or not so much wrong as redundant with what config(8) already does. >>>> IIRC, it was put in there as a stop-gap compatibility thing and it can >>>> now actually be removed (although it makes things nicer for John's patch). >>> Err, I'd rather remove the code from config? config can't handle the kmod.mk >>> and include/Makefile cases and it is easier to verify the logic is identical >>> for the three cases if all three are done in Makefiles rather than having two >>> of them done via Makefiles and one done via config. >> Yea, the current behavior in config is to match NetBSD's approach (both >> at the time years ago, and now) >>> Honestly, I also prefer that we do kernel build stuff in the Makefiles rather >>> than config when possible since config is much more of a black box. Putting >>> things in config is also a bit more fragile. >> Config knows things that the make system might not know. It has been >> used to create the proper environment to build in. That's its job. >> >> Having said that, we can have config just export that information when >> generating its Makefiles. It dates from a time when it was difficult to >> do things in a Makefile, so it makes sense to reevaluate what we're >> doing with config. >> >> One example: We should have it set MACHINE and MACHINE_ARCH in the >> generated Makefile. We've hacked things to include and/or rely on them >> being set, but right now have them in the Makefiles. This isn't quite >> right anymore, so moving the code into config to export this >> information, and moving things out of config like the symbolic links >> makes sense. But we'll need to bump the config version to do this >> properly since there's compatibility issues if we're not careful... > It turns out our Makefiles were already fixed by ru@ to handle this properly > and config already exports the path to the source directory in the generated > Makefile. ru@ had planned on removing the code to generate symlinks from > config but didn't do it. My makefile changes to generate the x86 link worked > fine with buildkernel (using config -d) even though config was not patched to > create the link because of ru@'s changes. I'm going to test just removing the > changes from config altogether. We've tried to make it possible for one config to be used on 7, 8 and 9. Please make sure this is still possible. Thanks! If that's all tested, then I'm cool with the changes... Warner