>>> On 11.09.18 at 16:04, wrote:
> So what would be the conclusion?
>
> I'm going to change timestamps format to decimal for all keyhandlers.
> But what about the format itself? Does existing plain ns PRI_stime have
> a chance to be acked?
Well, if everyone else thinks this is a good idea, the
On 09/11/2018 03:04 PM, Andrii Anisov wrote:
> So what would be the conclusion?
>
> I'm going to change timestamps format to decimal for all keyhandlers.
> But what about the format itself? Does existing plain ns PRI_stime have
> a chance to be acked?
>
> Or should I think of an extended format (
So what would be the conclusion?
I'm going to change timestamps format to decimal for all keyhandlers.
But what about the format itself? Does existing plain ns PRI_stime have
a chance to be acked?
Or should I think of an extended format (seconds with fractions, ms with
fractions)?
On 11.09
On 09/11/2018 10:33 AM, Jan Beulich wrote:
On 11.09.18 at 11:24, wrote:
>> On 09/11/2018 09:50 AM, Andrii Anisov wrote:
>>> Hello Jan,
>>>
>>>
>>> On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number withou
On 11.09.18 12:33, Jan Beulich wrote:
Well, what should I say - I disagree. I would agree if it would be a
whole lot of work, but there's not that many key handlers to begin
with, and far not all of them print a time stamp in their headlines.
I'm quite ok with that.
--
*Andrii Anisov*
On 11.09.18 12:30, Jan Beulich wrote:
Should we think about replacing PRI_stime?
Why not, but that would require adding another %p suffix or
introducing a construct splitting s_time_t values into two pieces
(to be used to hide the two printk() arguments required).
I don't think that splitting
>>> On 11.09.18 at 11:28, wrote:
> On 09/11/2018 10:18 AM, Jan Beulich wrote:
> On 11.09.18 at 11:15, wrote:
>>> On 11/09/18 10:10, Jan Beulich wrote:
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that rea
>>> On 11.09.18 at 11:24, wrote:
> On 09/11/2018 09:50 AM, Andrii Anisov wrote:
>> Hello Jan,
>>
>>
>> On 11.09.18 11:27, Jan Beulich wrote:
>>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>>> digit decimal number without any separators is any easier than the
>>> curre
>>> On 11.09.18 at 11:21, wrote:
> On 11.09.18 12:18, Jan Beulich wrote:
>> What other separator do you suggest? I consider it quite helpful
>> to have one when there are more than about 10 digits. (I'd also
>> be fine, btw, to have the time printed in decimal, but then
>> perhaps with ms granula
On 09/11/2018 10:18 AM, Jan Beulich wrote:
On 11.09.18 at 11:15, wrote:
>> On 11/09/18 10:10, Jan Beulich wrote:
>> On 11.09.18 at 10:50, wrote:
On 11.09.18 11:27, Jan Beulich wrote:
> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
> digit decimal num
>>> On 11.09.18 at 11:20, wrote:
> On 11/09/18 10:18, Jan Beulich wrote:
> On 11.09.18 at 11:15, wrote:
>>> On 11/09/18 10:10, Jan Beulich wrote:
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading
On 09/11/2018 09:50 AM, Andrii Anisov wrote:
> Hello Jan,
>
>
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>> digit decimal number without any separators is any easier than the
>> current format.
> It's quite subjective. IMHO ti
On 11.09.18 12:18, Jan Beulich wrote:
What other separator do you suggest? I consider it quite helpful
to have one when there are more than about 10 digits. (I'd also
be fine, btw, to have the time printed in decimal, but then
perhaps with ms granularity and 6 digits for the fractional part.)
S
On 11/09/18 10:18, Jan Beulich wrote:
On 11.09.18 at 11:15, wrote:
>> On 11/09/18 10:10, Jan Beulich wrote:
>> On 11.09.18 at 10:50, wrote:
On 11.09.18 11:27, Jan Beulich wrote:
> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
> digit decimal number w
On 11.09.18 12:10, Jan Beulich wrote:
It is subjective, yes, but in such a case you even more so need to
demonstrate a change is an overall improvement.
I would phrase it as "printing timestapms in timestamp format".
--
*Andrii Anisov*
___
Xen-dev
>>> On 11.09.18 at 11:15, wrote:
> On 11/09/18 10:10, Jan Beulich wrote:
> On 11.09.18 at 10:50, wrote:
>>> On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number without any separators is any easier than the
On 11/09/18 10:10, Jan Beulich wrote:
On 11.09.18 at 10:50, wrote:
>> On 11.09.18 11:27, Jan Beulich wrote:
>>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>>> digit decimal number without any separators is any easier than the
>>> current format.
>> It's quite subje
>>> On 11.09.18 at 10:50, wrote:
> On 11.09.18 11:27, Jan Beulich wrote:
>> NAK, for two reasons: I'm not of the opinion that reading a 15 or more
>> digit decimal number without any separators is any easier than the
>> current format.
> It's quite subjective. IMHO timestamps measured in ns easier
Hello Jan,
On 11.09.18 11:27, Jan Beulich wrote:
NAK, for two reasons: I'm not of the opinion that reading a 15 or more
digit decimal number without any separators is any easier than the
current format.
It's quite subjective. IMHO timestamps measured in ns easier to
understand in decimals rath
>>> On 11.09.18 at 08:53, wrote:
> --- a/xen/common/perfc.c
> +++ b/xen/common/perfc.c
> @@ -33,8 +33,7 @@ void perfc_printall(unsigned char key)
> unsigned int i, j;
> s_time_t now = NOW();
>
> -printk("Xen performance counters SHOW (now = 0x%08X:%08X)\n",
> - (u32)(now
20 matches
Mail list logo
