From: Alexey Dobriyan <adobriyan@gmail.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Christoph Hellwig <hch@lst.de>, Kees Cook <keescook@chromium.org>,
Justin Stitt <justinstitt@google.com>,
Keith Busch <kbusch@kernel.org>, Jens Axboe <axboe@kernel.dk>,
Sagi Grimberg <sagi@grimberg.me>,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org, ksummit@lists.linux.dev
Subject: Re: the nul-terminated string helper desk chair rearrangement
Date: Fri, 27 Oct 2023 21:32:24 +0300 [thread overview]
Message-ID: <c9dd71ba-bb29-4e2d-b8cc-d49d493ffb32@p183> (raw)
In-Reply-To: <CAMuHMdV9CcjGkpF=FGe_U5XtbF08bKTEYkPSxArO1zBwnug0Wg@mail.gmail.com>
On Thu, Oct 26, 2023 at 03:59:28PM +0200, Geert Uytterhoeven wrote:
> Hi Steven,
>
> On Thu, Oct 26, 2023 at 3:52 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> > On Thu, 26 Oct 2023 07:39:44 -0400
> > James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> >
> > > While it's nice in theory to have everything documented, it's not much
> > > use if no one can actually find the information ...
> >
> > Does kerneldoc provide an automated index? That is, if we had a single file
> > that had every function in the kernel that is documented, with the path to
> > the file that documents it, it would make finding documentation much
> > simpler.
> >
> > Maybe it already does? Which would mean we need a way to find the index too!
>
> ctags?
ctags is a tool from previous century. It doesn't help that "make tags"
is single-threaded. It needs constant babysitting (loop-like macros,
ignore attibute annotations which masquerade as identifiers). I think
"make tags" became much slower because ignore-list is one giant regexp
which only grows bigger.
> Although "git grep" is faster (assumed you use the "correct" search
> pattern, which can sometimes be challenging, indeed).
I tried QT Creator indexing at some point (which is parallel), it needs
to be told that headers are C not C++. I didn't find a way to tell it
that .c files are C too but F2 jumped to definitions quite well.
Also hovering over identifier/name works (being IDE it understands
popular doc styles).
It can be made to work reasonably well provided that you did "make
allmodconfig" and added few header locations. clangd parses like compiler,
not like human and kernel uses a lot of CONFIG defines so some config
must be chosen.
But I need to recheck all this stuff now that new version was propagated
to distros. It should be better (and less segfaulty :-)
next prev parent reply other threads:[~2023-10-27 18:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20231018-strncpy-drivers-nvme-host-fabrics-c-v1-1-b6677df40a35@google.com>
2023-10-19 5:46 ` the nul-terminated string helper desk chair rearrangement, was: Re: [PATCH] nvme-fabrics: replace deprecated strncpy with strscpy Christoph Hellwig
2023-10-19 6:01 ` the nul-terminated string helper desk chair rearrangement Kees Cook
2023-10-19 7:01 ` Willy Tarreau
2023-10-19 11:40 ` Alexey Dobriyan
2023-10-19 12:00 ` Willy Tarreau
2023-10-20 4:46 ` Christoph Hellwig
2023-10-20 17:40 ` Justin Stitt
2023-10-20 17:56 ` Linus Torvalds
2023-10-20 18:22 ` Kees Cook
2023-10-20 18:30 ` Kees Cook
2023-10-26 10:01 ` Christoph Hellwig
2023-10-26 11:39 ` James Bottomley
2023-10-26 13:52 ` Steven Rostedt
2023-10-26 13:59 ` Geert Uytterhoeven
2023-10-27 18:32 ` Alexey Dobriyan [this message]
2023-10-26 14:05 ` Jonathan Corbet
2023-10-27 7:08 ` Kalle Valo
2023-10-26 13:44 ` Andrew Lunn
2023-10-26 13:51 ` Laurent Pinchart
2023-10-26 14:27 ` James Bottomley
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=c9dd71ba-bb29-4e2d-b8cc-d49d493ffb32@p183 \
--to=adobriyan@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=axboe@kernel.dk \
--cc=geert@linux-m68k.org \
--cc=hch@lst.de \
--cc=justinstitt@google.com \
--cc=kbusch@kernel.org \
--cc=keescook@chromium.org \
--cc=ksummit@lists.linux.dev \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=rostedt@goodmis.org \
--cc=sagi@grimberg.me \
/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