linux-kernel - Re: [PATCH 00/10] Documentation/Sphinx

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:	Mon, 30 May 2016 17:29:30 +0200
From:	Daniel Vetter <daniel.vetter@...ll.ch>
To:	Jani Nikula <jani.nikula@...el.com>
Cc:	Markus Heiser <markus.heiser@...marit.de>,
	Jonathan Corbet <corbet@....net>,
	Grant Likely <grant.likely@...retlab.ca>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>,
	Dan Allen <dan@...ndevise.io>,
	Russel Winder <russel@...der.org.uk>,
	Keith Packard <keithp@...thp.com>,
	LKML <linux-kernel@...r.kernel.org>, linux-doc@...r.kernel.org,
	Hans Verkuil <hverkuil@...all.nl>
Subject: Re: [PATCH 00/10] Documentation/Sphinx

I concur with Jani on all points, just want to follow-up here.

On Mon, May 30, 2016 at 4:46 PM, Jani Nikula <jani.nikula@...el.com> wrote:
>> Many of the facts mentioned above have been covered in my POC at
>> https://github.com/return42/sphkerneldoc ... On others,
>> like 5. I'am working on ....
>>
>>> I've had a few moments of spare time to look into Sphinx.
>>
>> ... a comprehensive solution needs time and will not be done in a
>> hurry. Please give me a week or may be two, then I could present
>> a much more comprehensive solution.
>
> Please do not underestimate the productivity of my moments of spare
> time. ;)
>
> My view of the whole is that we've been talking about adding lightweight
> markup support for the better part of a year now, and I'm getting pretty
> tired of talking...

Tbh I'd like to get this in soonish, so that we have about 1 month of
time before 4.8 for actually polishing gpu documentation. Maybe
there's some room for more, better tables, other extensions, polish
the kernel-doc script a bit more. But what we have now works, I think
it does address everything we've discussed over the past year that we
absolutely need. I think it makes it possible to extend for all the
more optional use-cases we need to be able to convert, and we can add
those extensions later on. And with Jani's big pile of kernel-doc
patches we now also have someone who understands that perl script,
which is awesome.

In short I want to go nuts improving the docs themselves and stop
discussing the tooling to build them. Can we please make this happen?

Note that Jani's already started to throw out our old ascidoc hacks in
the topic/kerneldoc branch in the drm-intel.git repo, and we'll switch
over the autobuilder for the 01.org docs as soon as that's done. We're
committed, I want this ;-)

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch