* [Qemu-devel] Commit 99a0949 (using the mailing list)
@ 2009-10-01 21:17 Anthony Liguori
2009-10-01 22:06 ` [Qemu-devel] " Anthony Liguori
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Liguori @ 2009-10-01 21:17 UTC (permalink / raw)
To: malc, Paul Brook; +Cc: qemu-devel@nongnu.org
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.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 3+ messages in thread
* [Qemu-devel] Re: Commit 99a0949 (using the mailing list)
2009-10-01 21:17 [Qemu-devel] Commit 99a0949 (using the mailing list) Anthony Liguori
@ 2009-10-01 22:06 ` Anthony Liguori
2009-10-02 15:53 ` Blue Swirl
0 siblings, 1 reply; 3+ messages in thread
From: Anthony Liguori @ 2009-10-01 22:06 UTC (permalink / raw)
To: malc, Paul Brook; +Cc: qemu-devel@nongnu.org
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.
Regards,
Anthony Liguori
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Qemu-devel] Re: Commit 99a0949 (using the mailing list)
2009-10-01 22:06 ` [Qemu-devel] " Anthony Liguori
@ 2009-10-02 15:53 ` Blue Swirl
0 siblings, 0 replies; 3+ messages in thread
From: Blue Swirl @ 2009-10-02 15:53 UTC (permalink / raw)
To: Anthony Liguori; +Cc: Paul Brook, qemu-devel@nongnu.org
On Fri, Oct 2, 2009 at 1:06 AM, Anthony Liguori <anthony@codemonkey.ws> 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;
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-10-02 15:53 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-01 21:17 [Qemu-devel] Commit 99a0949 (using the mailing list) Anthony Liguori
2009-10-01 22:06 ` [Qemu-devel] " Anthony Liguori
2009-10-02 15:53 ` Blue Swirl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).