lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 16 Aug 2015 22:10:58 -0600
From:	Jonathan Corbet <corbet@....net>
To:	Danilo Cesar Lemes de Paula <danilo.cesar@...labora.co.uk>
Cc:	linux-doc@...r.kernel.org, Randy Dunlap <rdunlap@...radead.org>,
	Daniel Vetter <daniel.vetter@...ll.ch>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Stephan Mueller <smueller@...onox.de>,
	Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [PATCH v2 1/4] scripts/kernel-doc: Adding cross-reference links
 to html documentation.

On Tue, 28 Jul 2015 16:45:15 -0300
Danilo Cesar Lemes de Paula <danilo.cesar@...labora.co.uk> wrote:

> Functions, Structs and Parameters definitions on kernel documentation
> are pure cosmetic, it only highlights the element.
> 
> To ease the navigation in the documentation we should use <links> inside
> those tags so readers can easily jump between methods directly.
> 
> This was discussed in 2014[1] and is implemented by getting a list
> of <refentries> from the DocBook XML to generate a database. Then it looks
> for <function>,<structnames> and <paramdef> tags that matches the ones in
> the database. As it only links existent references, no broken links are
> added.

So I had some airplane time today and was able to mess with this some.  I
can't make it break anymore, and it clearly improves the resulting
documentation, so I've applied it to the docs tree for 4.3.

I want to look at the rest of the stuff a bit more and play with it, but
it's hard to imagine why we wouldn't want that as well.  I'm a bit more
leery just because it adds another dependency to the build, even if it's
an optional dependency.  My thinking at the moment is to apply it shortly
after the merge window so it can have a long soak in linux-next before a
4.4 merge; hope that sounds good.

Thanks for doing this work,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ