Date: Tue, 02 Nov 2010 18:07:35 -0600 (MDT) From: Warner Losh <imp@bsdimp.com> To: uqs@spoerlein.net Cc: attilio@freebsd.org, arch@freebsd.org Subject: Re: [PATCH] Headers for the x86 subtree Message-ID: <20101102.180735.74725412.imp@bsdimp.com> In-Reply-To: <20101028205815.GF46314@acme.spoerlein.net> References: <AANLkTiktoYyxmE8nyGeoc4_ov35fR7iN83444MfhYg-e@mail.gmail.com> <20101028205815.GF46314@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
From: Ulrich Sp=F6rlein <uqs@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 a= nd > > 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): th= e > > files under machine/include/* became just mere stubs for x86/includ= e/* > > 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 mov= ing > > other files as time permits. > = > What I don't quite get with the new x86 directory is, why we didn't m= ake > 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... Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101102.180735.74725412.imp>