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/...

[Kostik Belousov]

On Thu, Feb 25, 2010 at 06:56:53PM -0700, M. Warner Losh wrote:
> In message: <3bbf2fe11002251732t35179d9ar3c3f39aafe75d5c2 at mail.gmail.com>
>             Attilio Rao <attilio at FreeBSD.org> writes:
> : 2010/2/26 Xin LI <delphij at gmail.com>:
> : > On Thu, Feb 25, 2010 at 3:48 PM, Attilio Rao <attilio at freebsd.org> wrote:
> : >> 2010/2/26 M. Warner Losh <imp at bsdimp.com>:
> : >>> In message: <201002251413.o1PEDdKV033584 at svn.freebsd.org>
> : >>>            Attilio Rao <attilio at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20100226/8c3b606f/attachment.pgp