[Top][All Lists]
[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: |
Jan Kiszka |
Subject: |
Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path() |
Date: |
Tue, 15 Jun 2010 15:00:23 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 |
Paul Brook wrote:
>> 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?
To avoid having to issue an "info qtree" in the middle of an
auto-completion for some other command.
>
> 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.
That's how my current implementation looks like.
>
>>> 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?
Inject interrupts via that bus (while exposing registers in some other
way). The m48t59 seems to fall in this category (unless I'm missing
something ATM).
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), (continued)
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(),
Jan Kiszka <=
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Markus Armbruster, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Jan Kiszka, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Alex Williamson, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Chris Wright, 2010/06/15
- Re: [Qemu-devel] [RFC PATCH 1/5] qdev: Create qdev_get_dev_path(), Paul Brook, 2010/06/15