qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: Commit 99a0949 (using the mailing list)


From: Blue Swirl
Subject: Re: [Qemu-devel] Re: Commit 99a0949 (using the mailing list)
Date: Fri, 2 Oct 2009 18:53:13 +0300

On Fri, Oct 2, 2009 at 1:06 AM, Anthony Liguori <address@hidden> wrote:
> Anthony Liguori wrote:
>>
>> I've reverted 99a0949.  It's not necessarily a bad change to make but
>> something that's so invasive as that absolutely requires some discussion
>> before hand.  Avoiding "bike-shedding" is not a valid argument for avoiding
>> the list.
>>
>> For instance, I find the naming to be truly awful and would have liked
>> some discussion on a more reasonable naming convention.
>>
>> I have a very large set of patches in my queue (over 200) that I'm testing
>> and trying to commit.  A lot of other people do.  If we're going to make a
>> change like this, it's very important to coordinate with people so that they
>> can flush their queues and avoid massive merge head-ache.
>
> After talking to malc, I have to take a fair bit of the blame here.  I made
> a comment in another thread that I thought that this sort of change was a
> good idea.  While I do think it's a good idea, I could have been more clear
> that it was a change that needed some more planning and discussion.

I think it would be logical to rename the structs with '_t' to
CamelCase and drop the '_t', like the other structs are named.

I don't know about scalars. It would be logical to use CamelCase as
well, but TargetPhysAddr or RAMAddr look like struct names.
target_phys_addr and ram_addr, maybe.

This also looked very suspicious:
-spinlock_t tb_lock = SPIN_LOCK_UNLOCKED;
+a_spinlock tb_lock = SPIN_LOCK_UNLOCKED;




reply via email to

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