[PATCH] Headers for the x86 subtree

Warner Losh imp at bsdimp.com
Fri Oct 29 01:57:26 UTC 2010


  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 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...
> 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


More information about the freebsd-arch mailing list