From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
Cc: "Pali Rohár" <pali.rohar@gmail.com>,
"Enrico Weigelt, metux IT consult" <info@metux.net>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
linux-ntfs-dev@lists.sourceforge.net
Subject: Re: [PATCH 2/2] drivers: input: mouse: alps: drop unneeded likely() call around IS_ERR()
Date: Wed, 21 Aug 2019 10:48:57 -0700 [thread overview]
Message-ID: <20190821174857.GD76194@dtor-ws> (raw)
In-Reply-To: <2cd7178e-9713-7678-a02d-dde91e990c1e@metux.net>
Hi,
On Wed, Aug 21, 2019 at 01:37:09PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 20.08.19 16:22, Pali Rohár wrote:
>
> Hi,
>
> > > In that case, wouldn't a comment be more suitable for that ?
> >
> > And why to add comment if current state of code is more-readable and
> > does not need it?
>
> Readability is probably a bit subjective :p
>
> With ongoing efforts of automatically identifying redundant code pathes,
> the current situation causes the same discussion coming up over and over
> again. Sooner or later somebody might get the idea to add a comment on
> that line, that it's exactly as intented :o
>
> OTOH, I'm unsure whether it's important to document that is particular
> error path is unlikely, while we don't do it in thousands of other
> places. IMHO, error pathes are supposed to be unlikely by nature,
> otherwise we wouldn't call it an error situation ;-)
>
> > People normally add comments to code which is problematic to understand
> > or is somehow tricky, no so obvious or document how should code behave.
>
> Yes, but isn't this case so obvious that it doesn't need any
> documentation at all ? Is it so important to never ever forget that this
> particular path is a rare situation ?
Because if I see "if (IS_ERR(...))" in an interrupt path I will try to
see if it can be optimized out, but in this particular case we document
it with explicit "unlikely" and I know that I do not need to bother.
The fact that there is unlikely in IS_ERR is an implementation detail.
It may be gone tomorrow. I do not want to have to remember all
implementation details of all kernel APIs and readjust the code all the
time as they are change underneath me.
Thanks.
--
Dmitry
prev parent reply other threads:[~2019-08-21 17:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-20 10:56 [PATCH 1/2] fs: ntfs: drop unneeded likely() call around IS_ERR() Enrico Weigelt, metux IT consult
2019-08-20 10:56 ` [PATCH 2/2] drivers: input: mouse: alps: " Enrico Weigelt, metux IT consult
2019-08-20 11:17 ` Pali Rohár
2019-08-20 12:21 ` Enrico Weigelt, metux IT consult
2019-08-20 14:22 ` Pali Rohár
2019-08-21 11:37 ` Enrico Weigelt, metux IT consult
2019-08-21 17:48 ` Dmitry Torokhov [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=20190821174857.GD76194@dtor-ws \
--to=dmitry.torokhov@gmail.com \
--cc=info@metux.net \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-ntfs-dev@lists.sourceforge.net \
--cc=lkml@metux.net \
--cc=pali.rohar@gmail.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.