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.
Arnd <><
On Fri, 20 Oct 2006, Arnd Bergmann wrote:
On Thursday 19 October 2006 05:30, Dwayne Grant McConnell wrote:
quoted
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:
quoted
signal1_type (%llu)
signal2_type (%llu)
These are fine, they can only ever be 1 or 0.
quoted
npc (%llx)
I think we used to access this in _very_ old versions of libspe,
before we move to a syscall based interface.
quoted
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.
quoted
phys_id (0x%llx)
This one is used in some forks of libspe, we should not change it.
quoted
object_id (0x%llx)
This is used in libspe, gdb and oprofile, but only in fairly recent
versions.
quoted
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.
quoted
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 [off-list ref]
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS
On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
I think %0xllx is the way to go. I would even advocate changing
signal1_type and signal2_type unless it is actually too dangerous.
There is absolutely no reason why these should be hexadecimal, they
are basically implementing a bool.
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?
Right, a library or some script that has been written assuming there
is no leading 0x.
Arnd <><
On Fri, 20 Oct 2006, Arnd Bergmann wrote:
On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
quoted
I think %0xllx is the way to go. I would even advocate changing
signal1_type and signal2_type unless it is actually too dangerous.
There is absolutely no reason why these should be hexadecimal, they
are basically implementing a bool.
quoted
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?
Right, a library or some script that has been written assuming there
is no leading 0x.
Okay. Thanks for considering it. I'll leave the %llu as is.
--
Dwayne Grant McConnell [off-list ref]
Lotus Notes Mail: Dwayne McConnell [Mail]/Austin/IBM@IBMUS
Lotus Notes Calendar: Dwayne McConnell [Calendar]/Austin/IBM@IBMUS
On Fri, 2006-10-20 at 16:38 +0200, Arnd Bergmann wrote:
On Friday 20 October 2006 15:54, Dwayne Grant McConnell wrote:
quoted
I think %0xllx is the way to go. I would even advocate changing
signal1_type and signal2_type unless it is actually too dangerous.
There is absolutely no reason why these should be hexadecimal, they
are basically implementing a bool.
quoted
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?
Right, a library or some script that has been written assuming there
is no leading 0x.
We might still want to "broadcast" that we might change that and see how
much gets broken. It's very likely that nothing will.
Ben.