From: Marc Zyngier <maz@kernel.org>
To: Edmundo Carmona Antoranz <eantoranz@gmail.com>
Cc: catalin.marinas@arm.com, will@kernel.org, avagin@gmail.com,
0x7f454c46@gmail.com, mark.rutland@arm.com, tglx@linutronix.de,
linux-arm-kernel@lists.infradead.org,
kernel-janitors@vger.kernel.org
Subject: Re: [PATCH -next] arm64: vdso: correct definition of macro vdso_clocksource_ok
Date: Sat, 10 Apr 2021 23:18:40 +0100 [thread overview]
Message-ID: <8735vxg4vz.wl-maz@kernel.org> (raw)
In-Reply-To: <CAOc6etaqPprFHidXwRy+wNWqDr9FXe2=dDN9H81ODHwXpbX5yA@mail.gmail.com>
On Sat, 10 Apr 2021 20:58:22 +0100,
Edmundo Carmona Antoranz <eantoranz@gmail.com> wrote:
>
> On Sat, Apr 10, 2021 at 1:03 PM Marc Zyngier <maz@kernel.org> wrote:
> >
> > Hi Edmundo,
>
> Sup!
>
> >
> >
> > No difference? Have you simply tried removing the macro and witness
> > the effect? If it made no difference, why have the macro at all then?
>
> Oh, come on! so having the macro defined so that you can do things like
>
> lib/vdso/gettimeofday.c:34:#ifndef vdso_clocksource_ok
>
> counts as "a difference" to you? XD ok ok ... so, I have deleted
> "extended linux kernel C preprocessor knowledge" from my linkedin
> profile.
If you want to look cool on Linkedin, the C preprocessor really is the
wrong thing to boast about. Consider adding things like iron oxide,
which will definitely boost your visibility.
> I can safely assume that this is a big resounding NACK, right? :-D
Not necessarily a NAK, because I don't like doing that. But I find
this an unnecessarily change and a fairly pointless divergence from an
established practice. Others may agree with you.
But it was worth pointing out that "it actually makes no difference to
have the macro defined or not" wasn't quite the right thing to put in
the commit message.
>
> >
> > Also, run this, for example:
> >
> > git grep '^\#define' arch/arm64/include/asm/| awk '$2 == $3 { print }'
> >
> > Are you going to "fix" these too?
> >
> > Thanks,
>
> Thank you for the lesson, man. Still have a lot of stuff to learn in
> front of me.
We all do.
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-04-10 22:20 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-10 18:11 [PATCH -next] arm64: vdso: correct definition of macro vdso_clocksource_ok Edmundo Carmona Antoranz
2021-04-10 19:03 ` Marc Zyngier
2021-04-10 19:58 ` Edmundo Carmona Antoranz
2021-04-10 22:18 ` Marc Zyngier [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=8735vxg4vz.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=0x7f454c46@gmail.com \
--cc=avagin@gmail.com \
--cc=catalin.marinas@arm.com \
--cc=eantoranz@gmail.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=tglx@linutronix.de \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).