qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Should we auto-generate IDs?


From: Markus Armbruster
Subject: Re: [Qemu-devel] Should we auto-generate IDs?
Date: Thu, 27 Aug 2015 07:39:34 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Programmingkid <address@hidden> writes:

> On Aug 26, 2015, at 6:08 PM, John Snow wrote:
>
>> 
>> 
>> On 08/26/2015 05:48 PM, Programmingkid wrote:
>>> 
>>> On Aug 26, 2015, at 2:45 PM, Peter Maydell wrote:
>>> 
>>>> On 26 August 2015 at 18:16, Programmingkid
>>>> <address@hidden> wrote:
>>>>> That is assuming they have the time and/or the interest in
>>>>> solving this problem. I
>>>>> suppose giving them some time to respond would be reasonable. I'm
>>>>> thinking if
>>>>> no consensus has been reached in one weeks time (starting today),
>>>>> we turn to
>>>>> Peter Maydell for the answer. Hopefully he will just pick which
>>>>> of the patches he
>>>>> likes the best. Judging by how long this problem has been ongoing, someone
>>>>> pick the answer is probably the best we can expect.
>>>> 
>>>> This is the kind of thing I strongly prefer to leave to the
>>>> relevant subsystem maintainer(s). My opinion is not worth
>>>> a great deal since I don't have a strong familiarity with
>>>> this bit of QEMU.
>>> 
>>> It looks unreasonable to assume any consensus can be reached over this 
>>> issue.
>>> The easy thing to do is to just let each maintainer deal with this problem
>>> his own way. 
>>> 
>> 
>> What feedback was there that seemed insurmountable? Last I talked to
>> Jeff Cody he said there was no "overwhelming pushback" against his
>> patches, just a list of concerns.
>
> Markus Armbruster sent me four different threads each trying to solve
> this problem.
> Some of those threads were many years old. The situation is the same then as 
> it
> is now. There is no judicator to decide how this problem is to be
> solved. Expecting
> all the maintainers to agree on one patch is unrealistic. 
>
>> This doesn't sound like a dead end so much as it sounds like we haven't
>> planned the feature enough yet.
>
> The threads did have some really good patches that did seem to solve
> the problem.
> I could send you the threads if you haven't read them yet.

Back then was then and now is now.  I understand your impatience to get
stuff done, but things may have changed, people may have changed.  We
really need to talk it over one more time.  If we can reach rough
consensus, swell.  If we can't, we can still narrow the scope to
subsystems where we can.

>>> Markus:
>>> I know you really wanted a single ID generating system, but it just
>>> isn't going
>>> to happen. I will make a patch that would only effect USB devices. All other
>>> devices would be untouched. At least the device_del problem will be solved.
>>> 
>> 
>> I think this is being unnecessarily hasty. We should make sure that an
>> auto-generated ID system does not create problems for other areas of
>> code before we rush ahead with one to solve a single problem.

Right.

> I would make sure my patch only affects USB devices. No other systems
> would be affected. 

Device IDs are in the qdev/QOM subsystem, so that's the subsystem you
have to attack should QEMU-wide consensus remain elusive.  The USB
subsystem is merely a user of qdev/QOM here.

>> Let's give the universal approach some more time before we jump to the
>> conclusion that it's impossible.
>
> I suppose 5 more years will do ;)
>
> Maybe that's too soon...

I understand your frustration with our collective inability to solve
this problem for 5+ years.  Heck, I share it!  I certainly don't want
the problem to be shelved *again*.  But a proper discussion should take
us perhaps days, at worst weeks (KVM Forum was last week, several folks
are taking time off right now), certainly not months, let alone years.

We can afford time for discussion.  That's how we work.  Rough consensus
and running code.  You're welcome to provide running code early, just be
prepared for it to be thrown out and redone :)



reply via email to

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