[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v2 02/15] qdev: Fix scanning across single-bus d

From: Jan Kiszka
Subject: Re: [Qemu-devel] [PATCH v2 02/15] qdev: Fix scanning across single-bus devices
Date: Sat, 29 May 2010 09:56:34 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv: Gecko/20080226 SUSE/ Thunderbird/ Mnenhy/

Markus Armbruster wrote:
> [cc: kraxel]
> Jan Kiszka <address@hidden> writes:
>> From: Jan Kiszka <address@hidden>
>> As long as we allow /dev.1 as shortcut for /dev1/bus1, we also have to
>> make sure that /dev1/dev2 works for /dev1/bus1/dev2/bus2 - as long as
>> there is only one child bus per device.
> We auto-root a path not starting with '/' via convention "first
> component is ID then" (I like that).  We auto-complete a path ending
> with a device when we want a bus (a bit too clever).  Auto-inserting bus
> names in the middle is too clever by half!
> Such cleverness can be convenient in the human monitor, but all it adds
> to QMP is complexity.
> I'm worried about possibly ambigous interpretation of paths.  Would be
> bad if a path could name different node after we add something to the
> tree.  I *think* your fine print makes that impossible, but it's not
> exactly obvious.  Heck, I could be wrong.

For the above example, that would mean a bus called 'dev2' would have to
be added to dev1. If that makes sense is one question. The other is why
this should be more broken than the case that this happens to a bus
specified at the end of some path?

> Wouldn't it be better to put the convenience into the interactive
> completion function?  That way we keep it out of QMP.

That would leave user interfaces over QMP broken behind, or at least
complicate their implementations as they would have to expand the qtree
path on their own to achieve consistency.

> Subject is misleading, it's a feature, not a bug fix.

Depends on the POV. For me it is a highly confusing inconsistency in the
way you can specify qtree paths. IMHO, we either have to drop this path
abbreviation or apply it to the whole path. As it's intention is
(according to my understanding) to ease the usage, an unintuitive
construction role is fairly counterproductive.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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