From: Martin Schwidefsky <schwidefsky@de.ibm.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
Xiao Guangrong <xiaoguangrong@cn.fujitsu.com>
Subject: Re: linux-next: tip tree build warnings
Date: Mon, 7 Sep 2009 10:59:28 +0200 [thread overview]
Message-ID: <20090907105928.2646cb11@skybase> (raw)
In-Reply-To: <20090903121326.GA4724@osiris.boeblingen.de.ibm.com>
On Thu, 3 Sep 2009 14:13:26 +0200
Heiko Carstens <heiko.carstens@de.ibm.com> wrote:
> On Thu, Sep 03, 2009 at 10:38:44AM +0200, Ingo Molnar wrote:
> > * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > > cputime_t is variously "u64", "unsigned long long" and "unsigned
> > > long" on different architectures.
> >
> > Should be unsigned long i think. Most architectures use it as
> > unsigned long via include/asm-generic/cputime.h, except these three:
> >
> > arch/ia64/include/asm/cputime.h:typedef u64 cputime_t;
> > arch/powerpc/include/asm/cputime.h:typedef u64 cputime_t;
> > arch/s390/include/asm/cputime.h:typedef unsigned long long cputime_t;
> >
> > Or we could eliminate the type altogether as well and standardize on
> > u64. Thomas?
>
> s390 uses 64 bit cputime_t because we want the high resolution also in
> 32 bit kernels. So standardizing on u64 would be the preferred solution
> for us.
The cputime_t type serves/served two purposes: 1) make it clear that
this is NOT a jiffie value, it is an architecture defined type with
architecture dependent semantic, 2) by redefining cputime_t to a
structure with a single embedded unsigned long I have been able to
identify all places in the kernel that do not use the proper cputime
functions. I'm not sure if we need 2) anymore.
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
prev parent reply other threads:[~2009-09-07 8:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-03 8:25 linux-next: tip tree build warnings Stephen Rothwell
2009-09-03 8:38 ` Ingo Molnar
2009-09-03 12:13 ` Heiko Carstens
2009-09-03 12:24 ` Heiko Carstens
2009-09-07 8:59 ` Martin Schwidefsky [this message]
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=20090907105928.2646cb11@skybase \
--to=schwidefsky@de.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
--cc=xiaoguangrong@cn.fujitsu.com \
/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.