From owner-freebsd-arch@FreeBSD.ORG Thu Oct 28 18:15:49 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 13C5F106564A; Thu, 28 Oct 2010 18:15:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BCFC78FC22; Thu, 28 Oct 2010 18:15:48 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 42C4546B1A; Thu, 28 Oct 2010 14:15:48 -0400 (EDT) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F09E28A01D; Thu, 28 Oct 2010 14:15:46 -0400 (EDT) From: John Baldwin To: Warner Losh Date: Thu, 28 Oct 2010 14:01:33 -0400 User-Agent: KMail/1.13.5 (FreeBSD/7.3-CBSD-20100819; KDE/4.4.5; amd64; ; ) References: <201010271355.40685.jhb@freebsd.org> <201010281249.37512.jhb@freebsd.org> <4CC9B3A7.60701@bsdimp.com> In-Reply-To: <4CC9B3A7.60701@bsdimp.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201010281401.33549.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Thu, 28 Oct 2010 14:15:47 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.96.3 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=4.2 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on bigwig.baldwin.cx 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: Thu, 28 Oct 2010 18:15:49 -0000 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. -- John Baldwin