qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 05/26] Unexport ticks_per_sec variable. Create g


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH 05/26] Unexport ticks_per_sec variable. Create get_ticks_per_sec() function
Date: Thu, 10 Sep 2009 19:39:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

malc <address@hidden> wrote:
> On Thu, 10 Sep 2009, Juan Quintela wrote:
>
>> malc <address@hidden> wrote:
>> > On Thu, 10 Sep 2009, Juan Quintela wrote:
>> >
>> >> malc <address@hidden> wrote:
>> >> > On Thu, 10 Sep 2009, Juan Quintela wrote:
>> >> >
>> >> > Point being?
>> >> >
>> >> > [..snip..]
>> >> 
>> >> See next patch.  We need to put the variable in one struct, we don't
>> >> want to change everything to read the variable from the struct.
>> >
>> > So put the in the _pre vmstate callback (or whatever it's called).
>> >
>> >> 
>> >> And at some point code, timer code have to move to qemu-timer.c code,
>> >> not in vl.c.
>> >
>> > So?
>> 
>> What is the problem with this approach?
>
> My problem with this patch is that it is completely pointless, 

Don't agree.

> touches a gob of places

Right, it happens each time that you changes an API, nothing new to see here.

> and the fact that you apparently never seen what a
> function call entails on PPC64 (any ABI).

Obviously I am not a expert on function calls, but if an architecture is
limiting the number of functions you can call -> Darwin will do his job.

>
> [..snip..]
>
>> My goal is having less global variables/state not more.  And your point
>> to have it as it is today?
>
> Yes, if it aint broke don't fix it.

Obviously, I can't disagree more with you.

Modularity, encapsulaption and _make sure_ that nobody can change this
variable becaues it is _not_ a variable are alien concepts here.

Later, Juan.





reply via email to

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