[PATCH] Headers for the x86 subtree

Warner Losh imp at bsdimp.com
Thu Oct 28 17:35:58 UTC 2010


  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 at freebsd.org>
>>> John Baldwin<jhb at freebsd.org>   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...

Warner

Warner




More information about the freebsd-arch mailing list