[PATCH] Headers for the x86 subtree

John Baldwin jhb at freebsd.org
Wed Oct 27 21:49:59 UTC 2010


On Wednesday, October 27, 2010 5:25:20 pm Attilio Rao wrote:
> 2010/10/27 John Baldwin <jhb at freebsd.org>:
> > On Wednesday, October 27, 2010 4:00:15 pm 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.
> >>
> >> So you probabilly are suggesting to go w/ the "pc98 approach".
> >> I'm fine with it, I'll try to look for how it works and implement as well.
> >
> > Thanks.  I think it is fine to use '#include <x86/foo.h>' in code directly
> > with this approach as well.  I only think we should provide wrappers in
> > /usr/include/machine if compatibility is needed.  mca.h and mptable.h
> > shouldn't need compatibility for example, but specialreg.h might.
> 
> I'd expect to potentially mirror any header, otherwise on which
> criterias we can say some are needed and other not?

If it is widely used in userland. :)  mptable.h is probably only used by the
mptable utility which is easily fixed.  It will not be of interest to any 3rd
party software.  mca.h may eventually be used by third party software, but it
is very new, so we can probably move it now without causing any harm.

Kernel-only headers such as intr_machdep.h certainly do not need any compat
wrappers.

We can always add a compat header in machine if we find it is needed, but I'd
like to minimize the amount of compat cruft as much as possible.

-- 
John Baldwin


More information about the freebsd-arch mailing list