public inbox for linux-kernel@vger.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: 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 11:47 UTC|newest]

Thread overview: 5+ 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 13:54   ` Correct way to format spufs file output Dwayne Grant McConnell
2006-10-20 14:38     ` Arnd Bergmann
2006-10-20 14:42       ` Dwayne Grant McConnell
2006-10-21  1:44       ` [Cbe-oss-dev] " 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox