On Thu, Feb 25, 2010 at 06:56:53PM -0700, M. Warner Losh wrote: > In message: <3bbf2fe11002251732t35179d9ar3c3f39aafe75d...@mail.gmail.com> > Attilio Rao <atti...@freebsd.org> writes: > : 2010/2/26 Xin LI <delp...@gmail.com>: > : > On Thu, Feb 25, 2010 at 3:48 PM, Attilio Rao <atti...@freebsd.org> wrote: > : >> 2010/2/26 M. Warner Losh <i...@bsdimp.com>: > : >>> In message: <201002251413.o1peddkv033...@svn.freebsd.org> > : >>> Attilio Rao <atti...@freebsd.org> writes: > : >>> : Author: attilio > : >>> : Date: Thu Feb 25 14:13:39 2010 > : >>> : New Revision: 204309 > : >>> : URL: http://svn.freebsd.org/changeset/base/204309 > : >>> : > : >>> : Log: > : >>> : Introduce the new kernel sub-tree x86 which should contain all the > code > : >>> : shared and generalized between our current amd64, i386 and pc98. > : >>> : > : >>> : This is just an initial step that should lead to a more complete > effort. > : >>> : For the moment, a very simple porting of cpufreq modules, BIOS > calls and > : >>> : the whole MD specific ISA bus part is added to the sub-tree but > ideally > : >>> : a lot of code might be added and more shared support should grow. > : >>> > : >>> Cool! > : >>> > : >>> : Sponsored by: Sandvine Incorporated > : >>> : Reviewed by: emaste, kib, jhb, imp > : >>> : Discussed on: arch > : >>> : MFC: 3 weeks > : >>> > : >>> Is this really wise? Are these changes KPI neutral? > : >> > : >> I don't think there are (still) KPI changes. > : >> Which one are you referring to? > : > > : > I think Warner means that there will be some header files to change > : > their location, making certain (I doubt there is any but just in case) > : > kernel modules maintained by third party to break (technically these > : > are not part of KPI but something that _could_ make third party > : > developers unhappy I guess). > : > : Yes but what is already compiled (thirdy-part modules included) will > : keep working without a glance. > > Yes, but modules can't be recompiled. That's why I said KPI rather > than KBI. > > : 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.
pgpPH0fUZfcPZ.pgp
Description: PGP signature
