Am 15.02.2013 12:41, schrieb Peter Maydell:
> On 15 February 2013 11:24, Andreas Färber wrote:
>> Am 15.02.2013 03:49, schrieb Antoine Mathys:
>>> First, the ds1338 code was in a poor state and never handled the 12 hour
>>> clock correctly. My first patch failed to fully fix the problem so I had
>
Il 15/02/2013 16:41, Antoine Mathys ha scritto:
> On 02/15/2013 12:24 PM, Andreas Färber wrote:
>> The expected answer would've been "take guest X and do Y to see Z", or
>> better to extend the existing qtest cases to prove something was broken
>> before and fixed afterwards and to avoid the same b
On 02/15/2013 12:24 PM, Andreas Färber wrote:
The expected answer would've been "take guest X and do Y to see Z", or
better to extend the existing qtest cases to prove something was broken
before and fixed afterwards and to avoid the same bug being reintroduced
later.
If we are talking about ad
On 15 February 2013 11:24, Andreas Färber wrote:
> Am 15.02.2013 03:49, schrieb Antoine Mathys:
>> First, the ds1338 code was in a poor state and never handled the 12 hour
>> clock correctly. My first patch failed to fully fix the problem so I had
>> to write a second one, but at no point did Pete
Antoine,
Am 15.02.2013 03:49, schrieb Antoine Mathys:
> First, the ds1338 code was in a poor state and never handled the 12 hour
> clock correctly. My first patch failed to fully fix the problem so I had
> to write a second one, but at no point did Peter or I introduce a
> regression, quite the op
Il 15/02/2013 03:49, Antoine Mathys ha scritto:
> First, the ds1338 code was in a poor state and never handled the 12 hour
> clock correctly. My first patch failed to fully fix the problem so I had
> to write a second one, but at no point did Peter or I introduce a
> regression, quite the opposite.
First, the ds1338 code was in a poor state and never handled the 12 hour
clock correctly. My first patch failed to fully fix the problem so I had
to write a second one, but at no point did Peter or I introduce a
regression, quite the opposite.
Second, I don't know where you got the idea that I
On 14 February 2013 12:17, Paolo Bonzini wrote:
> Il 14/02/2013 12:44, Andreas Färber ha scritto:
>> What seems more likely is that we would
>> have written a qtest which checked for the same wrong
>> behaviour we incorrectly put into the code, which
>> doesn't help anybody.
>
> Hmm, that's not ho
Am 14.02.2013 13:17, schrieb Paolo Bonzini:
> Il 14/02/2013 12:44, Andreas Färber ha scritto:
>> What seems more likely is that we would
>> have written a qtest which checked for the same wrong
>> behaviour we incorrectly put into the code, which
>> doesn't help anybody.
>
> Hmm, that's not how I
Il 14/02/2013 12:29, Andreas Färber ha scritto:
> I may be repeating myself here, but adding qtests as requested would've
> caught this. And they should even more be added to avoid regressions.
> There's even templates to copy for RTC, and the new Big Endian-safe
> {read,write}[bwlq]() functions fo
Il 14/02/2013 12:44, Andreas Färber ha scritto:
> What seems more likely is that we would
> have written a qtest which checked for the same wrong
> behaviour we incorrectly put into the code, which
> doesn't help anybody.
Hmm, that's not how I write tests... You write them as black boxes, and
if
Am 14.02.2013 12:11, schrieb Peter Maydell:
> On 14 December 2012 22:53, Antoine Mathys wrote:
>> The proper mapping between 24 hours and 12 hours modes is:
>> 0 12 AM
>> 1-111-11 AM
>> 12 12 PM
>> 13-23 1-11 PM
>> Fix code accordingly.
>>
>> Signed-off-by: Antoine Mathys
>
> So
On 14 February 2013 11:29, Andreas Färber wrote:
> Am 14.02.2013 12:11, schrieb Peter Maydell:
>> On 14 December 2012 22:53, Antoine Mathys wrote:
>>> The proper mapping between 24 hours and 12 hours modes is:
[snip]
>> (and I've had confirmation from somebody that this change
>> makes us match
On 14 February 2013 11:44, Andreas Färber wrote:
> Am 14.02.2013 12:32, schrieb Peter Maydell:
>> On 14 February 2013 11:29, Andreas Färber wrote:
>>> I may be repeating myself here, but adding qtests as requested would've
>>> caught this.
>>
>> Er, only if the tests were testing for the right th
Am 14.02.2013 12:32, schrieb Peter Maydell:
> On 14 February 2013 11:29, Andreas Färber wrote:
>> Am 14.02.2013 12:11, schrieb Peter Maydell:
>>> On 14 December 2012 22:53, Antoine Mathys wrote:
The proper mapping between 24 hours and 12 hours modes is:
> [snip]
>
>>> (and I've had confirma
On 14 December 2012 22:53, Antoine Mathys wrote:
> The proper mapping between 24 hours and 12 hours modes is:
> 0 12 AM
> 1-111-11 AM
> 12 12 PM
> 13-23 1-11 PM
> Fix code accordingly.
>
> Signed-off-by: Antoine Mathys
Sorry, I missed this patch earlier.
Reviewed-by: Peter Mayde
The proper mapping between 24 hours and 12 hours modes is:
0 12 AM
1-111-11 AM
12 12 PM
13-23 1-11 PM
Fix code accordingly.
Signed-off-by: Antoine Mathys
---
hw/ds1338.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/hw/ds1338.c b/hw/ds1338.c
inde
17 matches
Mail list logo