[PATCH] Headers for the x86 subtree

Warner Losh imp at bsdimp.com
Fri Oct 29 16:02:44 UTC 2010


  On 10/29/2010 09:35, Tijl Coosemans wrote:
> On Friday 29 October 2010 15:40:17 John Baldwin wrote:
>> On Thursday, October 28, 2010 5:31:09 pm Tijl Coosemans wrote:
>>> On Thursday 28 October 2010 16:13:02 John Baldwin wrote:
>>>> On Thursday, October 28, 2010 3:44:21 am Attilio Rao wrote:
>>>>> 2010/10/27 John Baldwin<jhb at freebsd.org>:
>>>>>> On Wednesday, October 27, 2010 10:56:06 am Attilio Rao wrote:
>>>>>>> This patch should convert a (simple and 100% shared between amd64 and
>>>>>>> i386 header) under the x86 sub-tree. Please note that in this patch I
>>>>>>> "svn cp" the file from sys/amd64/include/mptable.h into
>>>>>>> sys/x86/include/mptable.h:
>>>>>>> http://www.freebsd.org/~attilio/headers-x86.diff
>>>>>>>
>>>>>>> This is someway a POC, that I really want to get in. The idea is
>>>>>>> simple and someway follows the pc98 case (even if not entirely): the
>>>>>>> files under machine/include/* became just mere stubs for x86/include/*
>>>>>>> contents and redirect there.
>>>>>>> This won't particulary help reducing the number of available files,
>>>>>>> but generally removing verbatim and would also be the way to go for
>>>>>>> handling MFCs.
>>>>>>> If you find this is the right way I'll commit the fix and start moving
>>>>>>> other files as time permits.
>>>>>> No, we want to do this differently because we also want this to work in
>>>>>> userland.  (e.g. I'd like to outright move mca.h to x86/include and then
>>>>>> use '#include<x86/mca.h>' in both kernel and userland for it).  We'd
>>>>>> need
>>>>>> some special glue to setup an 'x86' symlink during a kernel build that
>>>>>> points to @/x86/include as we do now to setup an 'i386' link for pc98
>>>>>> kernels.
>>>>>>
>>>>>> We'd also need to install the x86 headers into /usr/include during an
>>>>>> installworld.  Warner has some more pointers on this I think.
>>>>> I spoke with Warner briefly about it.
>>>>> One question I'm having now, though, is how getting co-living of pc98
>>>>> and x86 now, as we are basically overriding the same infrastructure
>>>>> (MACHINE_CPUARCH) in the i386/amd64 case?
>>>>> Do you have ideas about that?
>>>> I'm still doing testing, but this seems to be working so far.  I am
>>>> moving mca.h as my current test.
>>>>
>>>> Index: include/Makefile
>>>> ===================================================================
>>>> --- include/Makefile	(revision 214386)
>>>> +++ include/Makefile	(working copy)
>>>> @@ -116,8 +116,11 @@
>>>>   .endfor
>>>>
>>>>   .if ${MACHINE} != ${MACHINE_CPUARCH}
>>>> -_MARCH=${MACHINE_CPUARCH}
>>>> +_MARCHS=	${MACHINE_CPUARCH}
>>>>   .endif
>>>> +.if ${MACHINE_CPUARCH} == "i386" || ${MACHINE_CPUARCH} == "amd64"
>>>> +_MARCHS+=	x86
>>>> +.endif
>>> Can't MACHINE_CPUARCH be set to "x86" in the i386, amd64 and pc98
>>> cases? This patch wouldn't be needed then.
>> As Warner said, we aren't quite ready for that yet.  However, even if we
>> do that, pc98 would need further help as it still needs /usr/include/i386
>> installed.  So that will require a code along the lines of:
>>
>> .if ${MACHINE} != ${MACHINE_CPUARCH}
>> _MARCHS=	${MACHINE_CPUARCH}
>> .endif
>> .if ${MACHINE} != ${MACHINE_ARCH}&&  ${MACHINE_ARCH} != ${MACHINE_CPUARCH}
>> _MARCHS+=	${MACHINE_ARCH}
>> .endif
>>
>> With pc98 having MACHINE=pc98, MACHINE_ARCH=i386, MACHINE_CPUARCH=x86.
> Ok, thanks. I'm interested in this mainly because to get "cc -m32"
> working on amd64, i386 headers would have to be installed there as
> well. I sent a patch similar to yours to this list a few months ago:
> http://lists.freebsd.org/pipermail/freebsd-arch/2010-August/010559.htmlsol
> http://people.freebsd.org/~tijl/cc-m32-2.diff
>
> One of the problems I encountered was that the build of kdump generates
> a file that includes all headers containing ioctl definitions. Both
> i386 and amd64 headers got included which caused conflicts. Moving
> common headers under x86 would solve that.
Well, mostly solve.  I'd love to see the x86 family of architectures 
have their machine/include files look like:

#ifdef PC98
#include <pc98/foo.h>
#elif defined(i386)
#include <i386/foo.h>
#elif defined(amd64)
#error That doesn't exist here
#endif

for files that are common, or mostly common.  That would go a long ways 
towards making -m32 work.  Then we'd install i386, pc98 and amd64 on all 
x86 architectures always and install the generated files as above in 
machine.  not sure how to specify pc98, since -m32 implies i386 not 
pc98...  But maybe support for pc98 generated code is yet another, 
orthogonal problem to -m32.  -mpc98 maybe needed, but the -m32 patches 
wouldn't be required to do that...

The big drawback of this is that the kernel builds would still using the 
raw headers, not via the intermediary include files.  While not a 
problem in theory, I wonder if there might be some weird edge cases that 
we mask doing that.  Given buildworld though, I kinda doubt we'd have 
undetected problems for long.

This is completely orthogonal to the common header problem john and 
atillio are trying to solve.

Warner


More information about the freebsd-arch mailing list