From: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
To: Jonathan Corbet <corbet@lwn.net>
Cc: linux-doc@vger.kernel.org, Matthew Wilcox <willy@infradead.org>,
Jani Nikula <jani.nikula@linux.intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] Docs: An initial automarkup extension for sphinx
Date: Mon, 24 Jun 2019 13:38:52 -0300 [thread overview]
Message-ID: <20190624133852.4a31c597@coco.lan> (raw)
In-Reply-To: <20190624082950.5e338d37@lwn.net>
Em Mon, 24 Jun 2019 08:29:50 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> On Sat, 22 Jun 2019 14:46:10 -0300
> Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
>
> > > > .. c:function:: int ioctl( int fd, int request, void *argp )
> > > > :name: v4l2-ioctl
> > >
> > > Some digging around didn't turn up any documentation for :name:, but it
> > > seems to prevent ioctl() from going into the list of functions that can be
> > > cross-referenced.
> >
> > It took me a while to discover this way to be able to re-define the
> > name of a symbol at the C domain, but I'm pretty sure I read this
> > somewhere at the Sphinx docs (or perhaps on some bug track or Stack
> > Overflow).
> >
> > I don't remember exactly where I get it, but I guess it is related to
> > this:
> >
> > http://docutils.sourceforge.net/docs/howto/rst-roles.html
> >
> > > I wonder if the same should be done for the others?
> >
> > Sure.
>
> It actually occurs to me that it might be better to keep the skip list and
> maybe expand it. There are vast numbers of places where people write
> open() or whatever(), and there is no point in even trying to
> cross-reference them.
Yeah, subsystems will likely have their own "man pages" for for sysctls.
Both the dvb and the v4l2 ones are part of what used to be the DocBook
manpages for those syscalls. If I'm not mistaken, we ended by expanded
the same approach for the media controller, for CEC and for RC.
> I should do some tests, it might even make a
> measurable difference in the build time to skip them :) And in any case,
> somebody is bound to put one of those common names into the namespace in
> the future, recreating the current problem.
There is one way of keeping it while avoiding troubles: you could
create internal names, for example using the current dir, auto-adding
the ":name:" tag when a declaration conflict rises. Not sure how
easy/hard would be to implement it.
Btw, at get_abi.pl, I had to do a trick like that, as some symbols
have a "local context". The good thing at ABI files is that the context
is clear: it is valid only between "What:" and "Description:" fields.
Also, as it is a single script that parses the entire ABI (it takes
on ~0.1 seconds to parse everything and store internally on my machine),
the logic there detects when an existing symbol is re-used on a different
context. When this happens, it adds a random char at the end of the
internal reference, while keeping the original name[1].
[1] on the the highly unlikely event that the new name still repeats,
it adds a new random char - until the name gets different.
Probably doing it at automarkup won't be that simple, but it could
work.
Thanks,
Mauro
next prev parent reply other threads:[~2019-06-24 16:38 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-21 23:51 [PATCH 0/3 v2] docs: function automarkup, now with 80% fewer regexes! Jonathan Corbet
2019-06-21 23:51 ` [PATCH 1/3] Docs: An initial automarkup extension for sphinx Jonathan Corbet
2019-06-22 1:00 ` Mauro Carvalho Chehab
2019-06-22 14:43 ` Jonathan Corbet
2019-06-22 17:46 ` Mauro Carvalho Chehab
2019-06-24 14:29 ` Jonathan Corbet
2019-06-24 16:38 ` Mauro Carvalho Chehab [this message]
2019-06-24 11:30 ` Jani Nikula
2019-06-24 14:25 ` Jonathan Corbet
2019-06-21 23:51 ` [PATCH 2/3] docs: remove :c:func: annotations from xarray.rst Jonathan Corbet
2019-06-21 23:51 ` [PATCH 3/3] kernel-doc: Don't try to mark up function names Jonathan Corbet
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=20190624133852.4a31c597@coco.lan \
--to=mchehab+samsung@kernel.org \
--cc=corbet@lwn.net \
--cc=jani.nikula@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=willy@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 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).