All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: cbe-oss-dev@ozlabs.org, linux-kernel@vger.kernel.org
Cc: linuxppc-dev@ozlabs.org, Dwayne Grant McConnell <decimal@us.ibm.com>
Subject: Re: Correct way to format spufs file output.
Date: Fri, 20 Oct 2006 10:23:10 +0200	[thread overview]
Message-ID: <200610201023.12796.arnd@arndb.de> (raw)
In-Reply-To: <Pine.WNT.4.64.0610182227120.6056@doodlebug>

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 <><

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: cbe-oss-dev@ozlabs.org, linux-kernel@vger.kernel.org
Cc: Dwayne Grant McConnell <decimal@us.ibm.com>, linuxppc-dev@ozlabs.org
Subject: Re: Correct way to format spufs file output.
Date: Fri, 20 Oct 2006 10:23:10 +0200	[thread overview]
Message-ID: <200610201023.12796.arnd@arndb.de> (raw)
In-Reply-To: <Pine.WNT.4.64.0610182227120.6056@doodlebug>

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 <><


       reply	other threads:[~2006-10-20  8:23 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <Pine.WNT.4.64.0610182227120.6056@doodlebug>
2006-10-20  8:23 ` Arnd Bergmann [this message]
2006-10-20  8:23   ` Correct way to format spufs file output Arnd Bergmann
2006-10-20 13:54   ` Dwayne Grant McConnell
2006-10-20 13:54     ` Dwayne Grant McConnell
2006-10-20 14:38     ` Arnd Bergmann
2006-10-20 14:38       ` Arnd Bergmann
2006-10-20 14:42       ` Dwayne Grant McConnell
2006-10-20 14:42         ` Dwayne Grant McConnell
2006-10-21  1:44       ` [Cbe-oss-dev] " Benjamin Herrenschmidt
2006-10-21  1:44         ` Benjamin Herrenschmidt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200610201023.12796.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=cbe-oss-dev@ozlabs.org \
    --cc=decimal@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.