From: "Satyam Sharma" <satyam.sharma@gmail.com>
To: "Andi Kleen" <ak@suse.de>
Cc: "Andres Salomon" <dilinger@queued.net>,
"Juergen Beisert" <juergen127@kreuzholzen.de>,
"Andrew Morton" <akpm@linux-foundation.org>,
"TAKADA Yoshihito" <takada@mbf.nifty.com>,
linux-kernel@vger.kernel.org,
"Jordan Crouse" <jordan.crouse@amd.com>,
"Andres Salomon" <dilinger@debian.org>,
"Alan Cox" <alan@lxorguk.ukuu.org.uk>
Subject: Re: [PATCH 1/1] i386: Geode's TSC is not neccessary to mark tu unstable
Date: Sun, 22 Jul 2007 21:47:06 +0530 [thread overview]
Message-ID: <a781481a0707220917m710f2df3x1a27bdbb523099d7@mail.gmail.com> (raw)
In-Reply-To: <200707191022.44572.ak@suse.de>
> > > On Sun, 15 Jul 2007 21:06:27 +0200
> > > Juergen Beisert <juergen127@kreuzholzen.de> wrote:
> > > > Replace NSC/Cyrix specific chipset access macros by inlined functions.
> > > > With the macros a line like this fails (and does nothing):
> > > > setCx86(CX86_CCR2, getCx86(CX86_CCR2) | 0x88);
> > > > With inlined functions this line will work as expected.
> > On Thursday 19 July 2007 03:02, Andrew Morton wrote:
> > >
> > > I don't get it. Why would the macros behave differently from inlined
> > > functions?
> On Thu, 19 Jul 2007 08:49:05 +0200
> Juergen Beisert <juergen127@kreuzholzen.de> wrote:
> >
> > X86 magic. The access order is important. The first access must always be the
> > offset at 0x22. This access enables the next access to 0x23 (data). If you do
> > it in wrong order, it fails. With the macros you get something like 0x22,
> > 0x22, 0x23, 0x23. With the inline functions 0x22,0x23,0x22,0x23.
On 7/19/07, Andres Salomon <dilinger@queued.net> wrote:
>
> Wow, that's a really cool bug; nice work! Don't forget to update
> arch/i386/kernel/cpu/mtrr/state.c, though; it uses setCx86() as well. It needs
> to include processor-cyrix.h.
On 7/19/07, Andi Kleen <ak@suse.de> wrote:
>
> It also needs some big fat comments
Ok, I was discussing macros-in-C on some other thread and got
reminded about this one. Anyway, I don't really think there was
anything weird / surprising about this case at all -- it's just another
manifestation of the same age-old time-tested advise all our respective
grandmothers have always given us:
Never pass arguments that have side-effects to macros.
Of course, ideally the user shouldn't even know that the API call he's
using is a macro or a function -- which puts the onus upon the person
who *wrote* that API to ensure that he doesn't write macros for what
could, and should, easily be functions. Macros are generally evil and
always horrible, all IMHO, of course.
Satyam
next prev parent reply other threads:[~2007-07-22 16:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 12:00 TAKADA Yoshihito
2007-07-15 19:06 ` Juergen Beisert
2007-07-15 23:59 ` TAKADA Yoshihito
2007-07-19 1:02 ` Andrew Morton
2007-07-19 6:49 ` Juergen Beisert
2007-07-19 7:17 ` Andres Salomon
2007-07-19 8:22 ` Andi Kleen
2007-07-19 8:52 ` Juergen Beisert
2007-07-19 9:25 ` Andi Kleen
2007-07-19 10:25 ` Juergen Beisert
2007-07-19 13:56 ` Andi Kleen
2007-07-20 18:21 ` Andrew Morton
2007-07-20 21:16 ` Andi Kleen
2007-07-22 16:17 ` Satyam Sharma [this message]
2007-07-19 8:52 ` Juergen Beisert
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=a781481a0707220917m710f2df3x1a27bdbb523099d7@mail.gmail.com \
--to=satyam.sharma@gmail.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=dilinger@debian.org \
--cc=dilinger@queued.net \
--cc=jordan.crouse@amd.com \
--cc=juergen127@kreuzholzen.de \
--cc=linux-kernel@vger.kernel.org \
--cc=takada@mbf.nifty.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 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®