Gleb Natapov <gleb@xxxxxxxxxx> writes: > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote: >> Gleb Natapov <gleb@xxxxxxxxxx> writes: >> >> > On Fri, Nov 05, 2010 at 03:04:05PM +0100, Markus Armbruster wrote: >> [...] >> >> >> >> There has been quite some discussion on "canonical path" on the list, >> >> >> >> but no consensus. Ironically, one of the places where we got stuck was >> >> >> >> ISA. You cut right through that, so that's progress. Maybe people >> >> >> >> aren't looking ;) >> >> >> > That is funny since the problem was already solved looong time ago. Just >> >> >> > look at Open Firmware device path. They are capable of addressing all >> >> >> > devices just fine, ISA devices included. What specific problem you had >> >> >> > with ISA bus? >> >> >> >> >> >> Lack of consensus. I was in favour of using I/O base, just like you do. >> >> >> There were worries about ISA devices not using any I/O ports. >> >> > There is a solution for that problem for almost 15 years and we are >> >> > still looking for consensus on qemu list?! Here is ISA device binding >> >> > spec for Open Firmware: http://playground.sun.com/1275/bindings/isa/isa0_4d.ps >> >> > If ISA device have no IO ports MMIO is used. >> >> >> >> Precedence should promote consensus, but it can't replace it. If you >> >> can push the list to consensus, more power to you. >> > I do not see disagreement right now :) You are saying you agree. Blue >> > Swirl asked me to use Open Firmware so I assume he agrees to. So who is >> > against and what are his arguments? >> >> Start here: >> >> http://lists.nongnu.org/archive/html/qemu-devel/2010-06/msg01618.html > > I saw this in fact. The wouldn't agree with this device path proposal > too. It mixes qemu internal names (which is a big no-no for my purpose) > and bus addresses. Paul made sensible points there and if you look > closely what he proposes is what I implemented here. Regarding ISA > ("busses that don't have a consistent addressing scheme" he called it) > he himself proposed to use address of the first IO port/memory region > as an ID. This is what is already implemented by my patch. You don't have to convince me; I was with Paul in that thread. Regarding DeviceInfo member name values being QEMU internal: hardly. They're ABI. They're what we use to identify device types on external interfaces including command line, human monitor and QMP. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
