qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()


From: Paul Brook
Subject: Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path()
Date: Tue, 15 Jun 2010 13:39:22 +0100
User-agent: KMail/1.13.3 (Linux/2.6.33-2-amd64; KDE/4.4.4; x86_64; ; )

> Paul Brook wrote:
> >>>> From user POV, driver names are very handly to address a device
> >>>> intuitively - except for the case you have tones of devices on the
> >>>> same bus that are handled by the same driver. For that case we need
> >>>> to augment the device name with a useful per-bus ID, derived from the
> >>>> bus address where available, otherwise based on instance numbers.
> >>> 
> >>> This is where I think you're missing a trick. We don't need to augment
> >>> the name, we just need to allow the bus id to be used instead.
> >> 
> >> I prefer having one name per device, both unique AND human-friendly.
> >> Adding yet another alias will solve only the first requirement. E.g.,
> >> which one should I present to the monitor user when listing a bus for
> >> auto-completion or path error reporting?
> > 
> > Autocompletion can report all of them.
> 
> Autocompletion can only provide what is later on parseable.

Of course.

> It doesn't
> help to see "e1000" and "03.0" as device addresses because you do not
> know their relation that way. Only combining the information into a
> single name does.

I don't get your argument here. Why shouldn't e1000 and @03.0 refer to the 
same device? Querying the device itself will tell you both, so it's not hard 
to figure out that they refer to the same thing. Either piece of information 
is sufficient, so why do we require both?

Note that autocompletion and enumeration for mechanical traversal are 
different problems. The former should include useful aliases for humans (i.e. 
both e1000 and @03.0). The latter should be limited to the unique values 
corresponding to canonical addresses (i.e. @03.0).

> >> Again readability: isa-serial.0 & isa-serial.1 is more intuitive than
> >> isa-serial.6 & isa-serial.7 just because there happen to be 6 other ISA
> >> devices registered before them.
> > 
> > I don't think either of these are intuitive. There's a good chance that
> > isa-serial.0 will not correspond to the first serial port in the guest.
> 
> Only if you start tweaking the base addresses. Then it will still
> correspond to the addition order AND the user should be aware of this
> special setup.

I'm pretty sure there are some machines that have both internal UARTs 
(considered to be the primary ports), and secondary ports on an ISA bus.

If you really want instance numbers, then they may make most sense appended to 
the driver name. However I think this should be independent of bus addressing, 
and bus addresses make most sense as the canonical address.

> > Much better would be allowing use of IO port or MMIO addresses to
> > identify ISA devices.  Some modification to the ISABus code may be
> > required to implement this.
> 
> Works for serial, but fails for ISA devices not occupying an address.

An ISA device without an IO/MMIO capabilities seems extremely unlikely. What 
exactly would such a device do?

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]