mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: eranian@gmail.com
Cc: Stephen Rothwell <sfr@canb.auug.org.au>,
	Andi Kleen <andi@firstfloor.org>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	mingo@elte.hu, x86@kernel.org
Subject: Re: [patch 05/24] perfmon: X86 generic code (x86)
Date: Wed, 26 Nov 2008 17:38:47 +0100 (CET)	[thread overview]
Message-ID: <alpine.LFD.2.00.0811261727200.3325@localhost.localdomain> (raw)
In-Reply-To: <7c86c4470811260556l3b161f1fx639d7ee02285a93@mail.gmail.com>

Stephane,

On Wed, 26 Nov 2008, stephane eranian wrote:
> > I have not yet found a good reason why it needs to use u64 instead of
> > using what's there already.
> >
> There is a good reason why we cannot use unsigned long. We must make sure
> all data structures exchanged between user mode and the kernel have fixed size.
> This way, we can have a 32-bit tool run unmodified on top of a 64-bit kernel AND
> we do not need trampoline code to marshall/unmarshall the parameters.

That's not a good reason at all. We have in kernel interfaces and
kernel-userspace interfaces. Making them the same is nice if it works,
but horrible if it imposes crappy hackery like the bitops wrappers.

> And yes, the abstraction for bitmask ops was introduced because of issues
> casting u64 -> unsigned long on Big-Endian32-bit machines such as PPC32.

Sorry, I think it is simply stupid.

You can keep the userspace interface u64 and use unsigned long for the
bitmasks in the kernel and take care of it in the user space interface
code and do the BE32 conversion when you copy stuff from and to user.

That's a single well defined place and does not add extra crappola
over the kernel especially not into hot pathes like the interrupt. 

Why do you want to do u64 -> u32 BE32 magic on every interrupt,
context switch etc., if you can do it once in the userspace interface ?

Thanks,

	tglx



  reply	other threads:[~2008-11-26 16:39 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-26  8:42 eranian
2008-11-26 11:33 ` Andi Kleen
2008-11-26 12:05   ` Stephen Rothwell
2008-11-26 12:22     ` Andi Kleen
2008-11-26 12:48       ` Stephen Rothwell
2008-11-26 13:32     ` Thomas Gleixner
2008-11-26 13:56       ` stephane eranian
2008-11-26 16:38         ` Thomas Gleixner [this message]
2008-11-27  9:51           ` stephane eranian
2008-11-27 10:56             ` Thomas Gleixner
2008-11-27 11:37               ` David Miller
2008-11-27 14:40                 ` Thomas Gleixner
2008-11-26 13:35 ` Thomas Gleixner
2008-11-26 14:00   ` Andi Kleen
2008-11-26 21:18     ` Thomas Gleixner
2008-11-26 21:37       ` stephane eranian
2008-11-26 23:16         ` Thomas Gleixner
2008-11-27  9:38           ` stephane eranian
2008-11-26 22:54     ` Thomas Gleixner
2008-11-27 10:06       ` Andi Kleen
2008-11-27 10:09         ` stephane eranian
2008-11-27 10:29           ` Thomas Gleixner
2008-11-27 11:31           ` Andi Kleen
2008-11-27 11:35             ` stephane eranian
2008-11-27 11:42               ` David Miller
2008-11-27 11:49                 ` Thomas Gleixner
2008-11-27 12:38                   ` Andi Kleen
2008-11-27 12:31                     ` stephane eranian
2008-11-27 12:46                       ` Andi Kleen
2008-11-27 13:32                       ` Thomas Gleixner
2008-11-27 13:37                         ` stephane eranian
2008-11-27 13:51                           ` Andi Kleen
2008-11-27 13:50                         ` Andi Kleen
2008-11-27 11:52               ` Peter Zijlstra
2008-11-27 12:04                 ` stephane eranian
2008-11-27 12:16                   ` Peter Zijlstra
2008-11-27 12:32               ` Andi Kleen
2008-11-27 12:28                 ` stephane eranian
2008-11-27 12:45                   ` Andi Kleen
2008-11-27 13:30                     ` stephane eranian
2008-11-27 13:49                       ` Andi Kleen
2008-11-27 13:47                         ` stephane eranian
  -- strict thread matches above, loose matches on Subject: below --
2008-11-25 21:36 eranian

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=alpine.LFD.2.00.0811261727200.3325@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=andi@firstfloor.org \
    --cc=eranian@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=sfr@canb.auug.org.au \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®