From: Jonathan Corbet <corbet@lwn.net>
To: Markus Heiser <markus.heiser@darmarit.de>
Cc: Mauro Carvalho Chehab <mchehab@infradead.org>,
Jani Nikula <jani.nikula@intel.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH v2 0/3] doc-rst:c-domain: fix some issues in the c-domain
Date: Fri, 16 Sep 2016 10:02:26 -0600 [thread overview]
Message-ID: <20160916100226.055683ed@lwn.net> (raw)
In-Reply-To: <1473232378-11869-1-git-send-email-markus.heiser@darmarit.de>
On Wed, 7 Sep 2016 09:12:55 +0200
Markus Heiser <markus.heiser@darmarit.de> wrote:
> according to your remarks I fixed the first and second patch. The third patch is
> resend unchanged;
OK, I've applied the first two, finally.
> > Am 06.09.2016 um 14:28 schrieb Jonathan Corbet <corbet@lwn.net>:
> >
> > As others have pointed out, we generally want to hide the difference
> > between functions and macros, so this is probably one change we don't
> > want.
>
> I read "probably", so there might be a chance to persuade you ;)
>
> I'm not a friend of *information hiding* and since the index is sorted
> alphabetical it does no matter if the entry is 'FOO (C function)' or 'FOO (C
> macro)'. The last one has the right information e.g. for someone how is looking
> for a macro. FOO is a function-like macro and not a function, if the author
> describes the macro he might use the word "macro FOO" but in the index it is
> tagged as C function.
Information hiding is the only way we can maintain the kernel and stay
sane. I have a hard time imagining why somebody would be looking for a
macro in particular; the whole idea is that they really shouldn't have to
care. So my inclination is to leave this one out, sorry.
Thanks,
jon
next prev parent reply other threads:[~2016-09-16 16:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-07 7:12 [PATCH v2 0/3] doc-rst:c-domain: fix some issues in the c-domain Markus Heiser
2016-09-07 7:12 ` [PATCH v2 1/3] doc-rst:c-domain: fix sphinx version incompatibility Markus Heiser
2016-09-07 7:12 ` [PATCH v2 2/3] doc-rst:c-domain: function-like macros arguments Markus Heiser
2016-09-07 7:12 ` [RFC v2 3/3] doc-rst:c-domain: function-like macros index entry Markus Heiser
2016-09-09 12:08 ` [PATCH v2 0/3] doc-rst:c-domain: fix some issues in the c-domain Mauro Carvalho Chehab
2016-09-09 12:25 ` Markus Heiser
2016-09-19 11:36 ` Markus Heiser
2016-09-19 15:00 ` Mauro Carvalho Chehab
2016-09-20 18:56 ` Markus Heiser
2016-09-20 19:00 ` Jonathan Corbet
2016-09-20 20:58 ` Mauro Carvalho Chehab
2016-09-22 12:08 ` Mauro Carvalho Chehab
2016-09-22 12:35 ` kernel-lintdoc parser - was: " Mauro Carvalho Chehab
2016-09-22 22:03 ` Markus Heiser
2016-09-22 23:58 ` Markus Heiser
2016-09-16 16:02 ` Jonathan Corbet [this message]
2016-09-17 9:45 ` Markus Heiser
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=20160916100226.055683ed@lwn.net \
--to=corbet@lwn.net \
--cc=jani.nikula@intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=markus.heiser@darmarit.de \
--cc=mchehab@infradead.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 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.