MFC of r180753: ABI problems?

[John Baldwin]

On Saturday 23 August 2008 05:50:34 pm M. Warner Losh wrote:
> In message: <200808230742.10902.jhb at freebsd.org>
>             John Baldwin <jhb at freebsd.org> writes:
> : On Saturday 23 August 2008 02:42:09 am M. Warner Losh wrote:
> : > In message: <200808212351.13464.max at love2party.net>
> : >
> : >             Max Laier <max at love2party.net> writes:
> : > : Hi,
> : > :
> : > : I'm wondering how to merge r180753 to stable/7 as luoqi@ has indicated
> : > : that he doesn't have time to take care of it right now.
> : > :
> : > : It seems that changing the size of pcicfgregs (aka struct pcicfg) 
which
> : > : is part of struct pci_devinfo is out of the question, right?  Ideas 
where
> : > : to store the HT related state or how to avoid storing the state are
> : > : welcome.
> : > :
> : > : The merge result is attached for reference.  This fix is essential for
> : > : many nforce based boards from ASUS which are rather common, I'm 
afraid. 
> : > : So it would be good to have this in 7.1/6.4, I think.
> : >
> : > I think this is OK.
> : >
> : > pcicfgregs is an internal to pci implementation detail.  You've added
> : > it at the end, so any leakage of the offsets won't matter.  All
> : > subclasses of pci would be affected.  Internal to the kernel isn't all
> : > that interesting, since they are all compiled at the same time.  This
> : > would only matter for modules.  Cardbus and acpi would be the only
> : > modules affected.  That would mean you couldn't boot a 7.0 kernel with
> : > a 7.1 set of modules or vice versa.  I'm not sure that is actually
> : > going to work anyway...
> : 
> : ACPI (and OFW's) PCI bus code isn't going to care, and I doubt cardbus is 
> : either.  Hmm, actually, cardbus doesn't, but ACPI actually does (acpi_pci 
> 
> CardBus' does because it creates a slightly larger pcicfgreg per device...

I thought it did but couldn't find it in the code.  ACPI is basically doing 
the same thing.

-- 
John Baldwin