qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 27/49] ac97: add active to the state


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 27/49] ac97: add active to the state
Date: Wed, 30 Sep 2009 15:57:18 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

malc <address@hidden> wrote:
> On Wed, 30 Sep 2009, Juan Quintela wrote:
>
>> malc <address@hidden> wrote:
>> >> >> There are more temporary variables in other devices, and this was the
>> >> >> way it was done there.  Normally I would have called it active_vmstate
>> >> >> to make that explicit, but here, it was also used for reset, that is 
>> >> >> the
>> >> >> way I named it with the _vmstate suffix.
>> >> >
>> >> > In any case the while i can understand the fear of malloc, nobody forces
>> >> > you to do that you can have a scratch space on the stack, with an some
>> >> > upper cap, that's the way it's done now anyhow, only the cap is stack 
>> >> > size
>> >> > reserved for the process and not something you have to choose.
>> >> 
>> >> You call new way a monstrosity, and now propose a solution that makes
>> >> the monster bigger?
>> >> 
>> >> I still stand behind the patch, and I still want it applied.
>> >> 
>> >
>> > And it wont be, not this part of it, not in this state.
>> 
>> Suggestions?  Because you are not telling me that you expect to move
>> something to the stack, reimplement alloca() and work from there was a
>> _real suggestion_?
>> 
>
> Yet somehow you are explecting me to solve the problems with your design
> for you, neat. Alloca can be used but is not strictly necessary.
>
> char buf[UPPER_CAP]; and maybe temp_fields that point to it and survive
> the period between pre/post functions, would suffice, but anyhow, it's 
> your problem to solve, to reiterate i'm quite happy with what is there
> now.

No.  Everywhere code changed as I changed in ac97.  And everybody
agrees.  And now you told that everybody else was wrong, and that the
only true way is changing everything else for a worse/uglier solution.
As I told before, you have commit access, you win.

Discussion is at the point:
- you will accept _any_ solution that means not changing ac97.  No
  compromises taken.
- I will not make VMState worse/uglier/more complex just to work-around
  your veto.

Patch don't goes in, you win and I have lost time porting ac97 to VMState.

Later, Juan.




reply via email to

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