[PATCH] Headers for the x86 subtree
imp at bsdimp.com
Wed Nov 3 00:14:36 UTC 2010
From: Ulrich Spörlein <uqs at spoerlein.net>
Subject: Re: [PATCH] Headers for the x86 subtree
Date: Thu, 28 Oct 2010 22:58:15 +0200
> On Wed, 27.10.2010 at 16:56:06 +0200, 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.
> What I don't quite get with the new x86 directory is, why we didn't make
> it arch/x86 from the start? The usual argument against moving
> architecture specific stuff to arch/ is that it will break diffs for
> vendors. Now with x86 and the merging we are breaking their stuff
> anyway, but we don't actually improve the clutter under /sys and even
> gain a new arch-specific dir, not under arch/
> Somehow, this seems like a missed opportunity for an often requested
> cleanup. :/
There's a couple of factors that militate against this change:
(1) arch/foo means something else in NetBSD and OpenBSD. There, it is
overloaded to mean both CPU-specific code, as well as machine
specific code. It might be cleaner to move to cpu/foo instead.
(2) If we moved to arch/x86, it would be the odd-man out, requiring
special cases in a number of places. To make it not the odd-man
out would be a lot of work.
(3) Given the historical debates about arch/foo, there's a residual
recoil issue: nobody wants to touch that electric fence again...
More information about the freebsd-arch