Re: [Qemu-devel] [PATCHv2 4/8] Store IDE bus id in IDEBus structure for easy access.

[Gleb Natapov]

On Sat, Nov 06, 2010 at 10:25:31AM +0100, Markus Armbruster wrote:
> Gleb Natapov <address@hidden> writes:
> 
> > On Fri, Nov 05, 2010 at 05:31:38PM +0100, Markus Armbruster wrote:
> >> Gleb Natapov <address@hidden> 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.
> 
So who should I convince :)? Alex? He is CCed. Jan? I do not see him
complaining here.

> 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.
Correct. They are ABI since they are user visible. But they describe
device type where I prefer to have a field that specifies device
functionality for cases when one driver handles multiple devices in a
guest. So to clarify: "name" will work (that is why I use it when
driver_name is not set), but I want something more optimal.

--
                        Gleb.