On Tue, Feb 05, 2013 at 03:45:38PM +0400, Michael Tokarev wrote: > 05.02.2013 15:31, Vadim Rozenfeld wrote: > >On Mon, 2013-02-04 at 08:41 -0600, Anthony Liguori wrote: > >>Vadim Rozenfeld <vroze...@redhat.com> writes: > > >>>http://msdn.microsoft.com/en-us/library/windows/hardware/gg463287.aspx > >> > >>That's a useful link, thanks. > >> > >>I don't see anything in that link that would strictly require us to > >>change the revision ID. It seems to focus on when the "software > >>interface changes". I take that to mean, "change the revision ID if an > >>old driver wouldn't work anymore" which makes complete sense. > >Right, nobody can force you to change the revision id. It's just a good > >engineering practice to increase RevID every time the HW interface has > >changed, and you expect some compatibility issue between the new HW and > >old drivers. In this case, if Windows cannot locate the INF file which > >matches the new device identification strings, it just reports that it > >cannot find a suitable driver. > >> > >>But adding feature bits an altering the config size doesn't constitute a > >>change in the software interface IMHO. > > > >I agree, feature bits are good. The only one problem with them, is that > >driver usually doesn't have access to PCI space during the driver > >loading phase. > > Vadim, can you please describe in a bit more details what the actual issue > here is, from the windows or windows driver point of view? Is it really > that bad that the config space size changed? Why it has this effect? > Is this size specified in the inf file somehow? Just for us to actually > understand the issue? > > Thanks! > > /mjt
This should be educational: https://github.com/YanVugenfirer/kvm-guest-drivers-windows/commit/10413d2bbef295cc0e0e75131147793ccc382155 -- MST
