Re: Correct way to format spufs file output.

On Fri, 20 Oct 2006, Arnd Bergmann wrote:

On Thursday 19 October 2006 05:30, Dwayne Grant McConnell wrote:
In a recent submission I added the lslr file and used "%llx" for the
format string. You mentioned that it should probably be "0x%llx" so it
would be clearly parsed as hex so I changed it in the next submission. But
I noticed that there seems to be some inconsistent usage of 0x as follows:

Thanks for bringing this up, I guess I screwed up in some way here, so
we should fix it up one way or another:

signal1_type (%llu)
signal2_type (%llu)

These are fine, they can only ever be 1 or 0.

npc (%llx)

I think we used to access this in _very_ old versions of libspe,
before we move to a syscall based interface.

decr (%llx)
decr_status (%llx)
spu_tag_mask (%llx)
event_mask (%llx)
event_status (%llx)
srr0 (%llx)

These are used exclusively for debugging purposes, and no publically
available version of gdb accesses them, so I guess we can still change
them, although it's not nice.

phys_id (0x%llx)

This one is used in some forks of libspe, we should not change it.

object_id (0x%llx)

This is used in libspe, gdb and oprofile, but only in fairly recent
versions.

lslr (0x%llx)

As this is introduced by your own patch, there is no precedent for
it yet.

Current kernels now also have 'cntl' (0x%08lx), which was introduced
in 2.6.19 and is so far unused. I guess we should change that one
to be consistant with the others as well.

Should all the %llx be changed to 0x%llx or should the 0x be dropped from
those that have it or is the inconsistency acceptable?

I'd rather have it consistant. Moreover, I guess the "%llx" format is
actually harmful, because that means you can not use the same format
for read and write. The simple_attr_write function currently uses
the simple_strtol helper to interpret the value written to it, and that
requires the input to be wither decimal, or hexadecimal with a preceding
0x. I'd suggest we change all files to take a 0x%llx format on output.

I think %0xllx is the way to go. I would even advocate changing
signal1_type and signal2_type unless it is actually too dangerous. Is
there even a case where changing from %llu to %0xllx would break things?
Perhaps with the combination of a old library with a new kernel?

--
Dwayne Grant McConnell <decimal@xxxxxxxxxx>
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Correct way to format spufs file output.
    ... This one is used in some forks of libspe, ... As this is introduced by your own patch, there is no precedent for ... I'd rather have it consistant. ... I guess the "%llx" format is ...
    (Linux-Kernel)
  • Re: Suggestion for the next RCTQ directory
    ... I believe the date format is set up to be consistant. ... How about consistent birthday date formatting? ... sort by birthday folks. ...
    (rec.crafts.textiles.quilting)
  • Re: Reading a Wnd structure...
    ... but bottom posting is *X guys way on their forums. ... Arkady ... got no problem with either format, as long as it is consistant throughout ...
    (microsoft.public.win32.programmer.kernel)
  • Re: TIme
    ... time value (format the cells as hh:mm:ss). ... > =Round do you think that would be consistant? ... > "Frank Kabel" wrote in message ...
    (microsoft.public.excel.worksheet.functions)