svn commit: r204309 - in head/sys: amd64/amd64 amd64/isa conf i386/bios i386/cpufreq i386/i386 i386/isa i386/xen isa modules/bios/smbios modules/bios/vpd modules/cpufreq pc98/pc98 x86 x86/bios x86/...

M. Warner Losh imp at bsdimp.com
Fri Feb 26 15:17:08 UTC 2010


In message: <3bbf2fe11002260557y484cf13bq76f7507c07ed3ebc at mail.gmail.com>
            Attilio Rao <attilio at freebsd.org> writes:
: 2010/2/26 Ed Maste <emaste at freebsd.org>:
: > [ About the i386/amd64/pc98 -> x86 merge ]
: >
: >> > : I think there have been already MFCed patches doing headers movements
: >> > : in the past.
: >> >
: >> > We've tried to keep the KPI upwardly compatible.  If files move, then
: >> > old code will potentially break.
: >>
: >> Yes, but there is very non-trivial cost of not merging this.
: >> It makes testing in HEAD of other patches less valuable for merges,
: >> and merges itself becomes more time-consuming and risking.
: >>
: >> Fortunately, I do not no dri, but I know that maintaining patches
: >> both for 7 and 8/HEAD of dri is a hell.
: >
: > For headers on older branches we can just leave backwards compatibility
: > stubs in the i386, amd64 and pc98 directories that include the header
: > from the new x86 directory.
: 
: Yes, I thought something along those lines, if we think it is worthy
: (I'm not very concerned about it right now).
: For the future, however, probabilly we would need to do something like
: pc98 already does wrt i386 (i386/include/ pc98/include/ amd64/include/
: just have files wrappers to the generic one under x86/include/ when
: necessary).

Yes.  If you're going to merge this to old branches, it is critical
that you do this so you don't break the compilation of modules on
those branches.

Warner


More information about the svn-src-head mailing list