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]
Message-ID: <20150803082319.GB24689@phenom.ffwll.local>
Date:	Mon, 3 Aug 2015 10:23:19 +0200
From:	Daniel Vetter <daniel@...ll.ch>
To:	Jonathan Corbet <corbet@....net>
Cc:	Danilo Cesar Lemes de Paula <danilo.cesar@...labora.co.uk>,
	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] scripts/kernel-doc Allow struct arguments documentation
 in struct body

On Sat, Aug 01, 2015 at 01:22:10PM +0200, Jonathan Corbet wrote:
> On Fri, 31 Jul 2015 18:06:45 -0300
> Danilo Cesar Lemes de Paula <danilo.cesar@...labora.co.uk> wrote:
> 
> > Describing arguments at top of a struct definition works fine
> > for small/medium size structs, but it definitely doesn't work well
> > for struct with a huge list of elements.
> > 
> > Keeping the arguments list inside the struct body makes it easier
> > to maintain the documentation.
> 
> Interesting approach.  I think it could make sense, but I fear pushback
> from a subset of maintainers refusing to accept this mode.  I wonder what
> it would take to get a consensus on allowing these in-struct comments?

At least in drm we have a lot of such comments (as non-kerneldoc) right
above struct members to explain some details. Common examples are:
- locks, with a description of what they protect and maybe also how they
  nest.
- vfunc ops structs, with a per-function description of what each hook
  does.
- tricky stuff which can't be described in one sentence only.

So it's not just huge structs by number of members, but huge by number of
comment lines. Trying to stuff that all into the top kerneldoc comment
means that it's much harder to jump to the right comment, and it's also
easier to ignore the comments (since it e.g. won't show up in the diff
context).

The current approach at least in drm is to duplicate comments and that
just results in inconsistency.
 
> I'm wondering if we need a kernel summit session on commenting
> conventions, markdown-in-kerneldoc, etc?  Maybe I'll stick a proposal out
> there.

Might be useful, but I'm not sure how many people really would actively
work on improving the tooling. The only comment I've seen is to maybe use
gtkdoc, but that would be a pain since it's slightly incompatible with
kerneldoc.

And it's the improved tooling I really need for my long-term plan to get
solid docs for drm & drm/i915. Next step is to start building a proper doc
writer team to make all the bits we already have into a consistent hole
(and nag developers to fill in the areas still undocumented). For that
I've already pulled Danilo's patches into the drm-intel integration tree
and I plan to use them for any further drm kerneldoc I write since we
really need them.

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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