On Wed, Jun 17, 2015 at 09:15:24PM +0200, Laszlo Ersek wrote: > On 06/17/15 20:54, Michael S. Tsirkin wrote: > > Right. But what I was discussing is a different issue. The point is > > that it does not make sense to have /pci@i0cf8 under two hierarchies: > > it's the same register. What happens is that you access /pci@i0cf8 and > > then *through that* you access another pci root. Not the other way > > around. The proposal thus is to switch to /pci@i0cf8/pci-root@N in > > seabios, > > For me this is still Question 1 -- 'everything in that pattern that is > not "N"'. > > You seem to care about the *semantics* of that OFW device path fragment. > I don't. First, the relevant IEEE spec is prohibitively hard for me to > interpret semantically. Second, there is no known firmware that actually > looks at the "i0cf8" unit-address term and decides *based on that term* > that it has to talk PCI via 0xCF8 and 0xCFC. In other words, the current > second node is entirely opaque in my interpretation. > > > unconditionally - not if (QEMU). > > This might qualify as some kind of semantic cleanup, but it will > nonetheless break the SeaBIOS boot options expressed in OFW notation > that are already persistently stored in cbfs, on physical machines. (As > far as I understood.) It might not break the Coreboot-SeaBIOS interface, > but it might invalidate preexistent entries that exist in the prior form > (wherever they exist on physical hardware). > > > And I thought Kevin agreed > > it's a good idea. > > > > Kevin - is this a good summary of your opinion? > > Kevin, please do answer.
It is true that it would "invalidate preexistent entries" for coreboot/seabios users that upgrade, but I think that is manageable. So I defer the syntax discussion and decisions to the QEMU developers that are doing the bulk of the work. -Kevin
