[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatt
From: |
Blue Swirl |
Subject: |
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting) |
Date: |
Sun, 6 May 2012 10:01:52 +0000 |
On Sun, May 6, 2012 at 9:46 AM, malc <address@hidden> wrote:
> On Sun, 6 May 2012, Blue Swirl wrote:
>
>> On Sun, May 6, 2012 at 9:03 AM, malc <address@hidden> wrote:
>> > On Sun, 6 May 2012, Blue Swirl wrote:
>> >
>> >> On Fri, May 4, 2012 at 2:37 AM, malc <address@hidden> wrote:
>> >> > On Fri, 4 May 2012, Andreas F?rber wrote:
>> >> >
>> >> >> Am 04.05.2012 02:41, schrieb Anthony Liguori:
>> >> >> > On 05/03/2012 02:58 PM, Peter Maydell wrote:
>> >> >> >> On 9 February 2012 13:46, Anthony Liguori<address@hidden> wrote:
>> >> >> >>> On 02/09/2012 03:48 AM, Markus Armbruster wrote:
>> >> >> >>>> You buried the one truly important sentence, let me dig it out
>> >> >> >>>> for you:
>> >> >> >>>>
>> >> >> >>>> *** Patches should always go to the mailing list ***
>> >> >> >>>>
>> >> >> >>>> Exceptions need justification. Responsible handling embargoed
>> >> >> >>>> security
>> >> >> >>>> issues may qualify. Style fixes certainly not.
>> >> >> >>>
>> >> >> >>> 100% agreed.
>> >> >> >>
>> >> >> >> I don't see anything in the mailing list archives corresponding
>> >> >> >> to commits f05ae537, f6af014e.
>> >> >> >>
>> >> >> >> No unreviewed patches should go double when we're in hardfreeze!
>> >> >> >
>> >> >> > These patches are admittedly trivial but it is important to stress
>> >> >> > the
>> >> >> > point that all patches need to go on the mailing list before being
>> >> >> > committed.
>> >> >> >
>> >> >> > It's an important part of keeping the development process inclusive.
>> >> >> > I
>> >> >> > don't think it's reasonable to ask for an Acked-by on something as
>> >> >> > simple as indentation changes but at the same time, there's no reason
>> >> >> > not to just post patches.
>> >> >>
>> >> >> The second patch is far from trivial!
>> >> >>
>> >> >> It unneededly breaks the build on ppc hosts (during the Hard Freeze!),
>> >> >> so that I can no longer compile-test my patch series against PowerKVM.
>> >> >
>> >> > As discussed on IRC, the feature does not work on PPC32, hence it's
>> >> > violently disabled, what's needed is a black/white list of AREG0 ready
>> >> > targets.
>> >>
>> >> I think disabling was a poor decision, didn't this code already work
>> >> in some cases? What's really needed is to shuffle the registers
>> >
>> > It didn't on Linux and BSDs, might have worked on Darwin and AIX.
>>
>> Then fix it, please!
>
> WTF? You commit broken code that is used by 9/10 of all PPC users (yes
> all 9 of them) and _then_, not before, demand to fix it.. shrug.
The same approach worked fine on x86. I don't know all architectures
and their ABIs, so I can't fix all back ends. You should be able to do
this much better. Is fixing the register order that hard?
>
>>
>> >> according to ABI and this shouldn't be much different to what was
>> >> already in.
>> >
>> > The code that was commited was
>> > a. Pathetically inneficient everywhere
>> > b. Wrong for SysV ABI
>>
>> Yes, that's what I told back then. There are too many ABIs for various
>> architectures, the maintainers should know these much better.
>
> Told whom?
The list at least, there were plenty of people involved in the discussions.
>
>>
>> >
>> >>
>> >> I have sent out AREG0 patches for ARM and PPC, also I have x86 patches
>> >> in preparation. When (if) these and maybe further conversions are
>> >> committed for 1.2, PPC host support will be practically nonexistent.
>> >> Is this what you want?
>> >
>> > What i do not want is code that doesn't work. And i take non-existant
>> > over wrong any day. I also would prefer to be notified when code which
>> > i maintain is modified.
>>
>> But your approach is not OK in any sense, now we have a failed build.
>> Before, we had code that could work in some cases and the other cases
>> could be probably easily fixed.
>>
>
> Well, here's a "sense", code that _silently_ misbehaves is NOT "OK".
Then fix the misbehaviour instead of this error approach, please.
>
> --
> mailto:address@hidden
- [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Peter Maydell, 2012/05/03
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Anthony Liguori, 2012/05/03
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Andreas Färber, 2012/05/03
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), malc, 2012/05/03
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Alexander Graf, 2012/05/04
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Blue Swirl, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), malc, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Blue Swirl, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), malc, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting),
Blue Swirl <=
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), malc, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Blue Swirl, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), malc, 2012/05/06
- Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Blue Swirl, 2012/05/06
- Re: [Qemu-devel] unreviewed commits, Andreas Färber, 2012/05/06
- Re: [Qemu-devel] unreviewed commits, Alexander Graf, 2012/05/06
- Re: [Qemu-devel] unreviewed commits, Richard Henderson, 2012/05/06
- Re: [Qemu-devel] unreviewed commits, Blue Swirl, 2012/05/06
Re: [Qemu-devel] unreviewed commits (was: Re: Restore consistent formatting), Peter Maydell, 2012/05/04