Date: Mon, 14 Jun 2010 12:51:45 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-arch@freebsd.org Cc: mdf@freebsd.org Subject: Re: arch-specific directories Message-ID: <201006141251.45896.jhb@freebsd.org> In-Reply-To: <AANLkTilFBdzdlf2ZcnHN6_ygiw8qkEAJX-G-R6uSF55K@mail.gmail.com> References: <AANLkTilFBdzdlf2ZcnHN6_ygiw8qkEAJX-G-R6uSF55K@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Monday 14 June 2010 11:26:45 am mdf@freebsd.org wrote: > This is as much as request for information as a suggestion. > > I am wondering of the current layout of sys/<arch> make sense given > that in several cases the only difference between two "arch" is the > bitness, e.g. powerpc and powerpc64. The 64-bit version supports a > few new instructions, but in many cases is the same. The same issue > exists with i386/amd64 but because both have been supported for a long > time the have full arch separation. However, there has been some > movement of files that are common between i386 and amd64 into a common > x86 directory. > > So what I'm wondering is it it makes more sense to have files broken > up more like: > > sys/<arch> for common file between bitness > sys/<arch>/32 > sys/<arch>/64 for files that are specific to the bitness > > This would presumably serve at least powerpc and i386/amd64 well, and > though I don't know for sure I assume at the moment that it works for > sun/sparc as well. > > So... is this reasonable? Or does the existence of ia64 throw a > monkey wrench into this layout? Is it not worth the shuffle (though > I'd argue that, if we're moving some files to x86 and creating a new > powerpc64 that it's better to consider now than later). > > I realize there was a discussion earlier along similar lines (the > bi-yearly architecture source tree layout discussion) but I don't > think it was specifically considering the 32/64 bit differences, which > seem to be more common now. I think for archs that share a lot in common between 32-bit and 64-bit varieties using shared sources of some sort (e.g. sys/x86) should be encouraged. This is probably more true (and feasible) for more recently added architectures such as powerpc, arm, and mips. Alpha and ia64 would not have fit into this category. Since we do not support 32-bit sparc, sparc64 doesn't really fit into it either. However, I think that some of our build infrastructure assumes that that the current MACHINE/TARGET is in the path, so e.g. make buildkernel uses sys/$TARGET/conf to find the kernel config file to build, so we may be stuck with some of the layout differences at the top-level. I suspect the arm, powerpc, and mips target names are already embedded at this point, but I would not mind an organization where common code lived in sys/mips and 32-bit and 64-bit bits lived in sys/mips32 and sys/mips64. (That would work with the existing kernel config path assumptions, but require changing 'arm' -> 'arm32', etc. for MACHINE/TARGET). I'm sure Warner has some ideas on this topic as well. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201006141251.45896.jhb>