On Thu, Dec 29, 2016 at 10:54:29AM +0000, Chris Wilson wrote:
On Thu, Dec 29, 2016 at 11:35:48AM +0100, Daniel Vetter wrote:
On Wed, Dec 28, 2016 at 05:37:26PM +0000, Chris Wilson wrote:
On Wed, Dec 28, 2016 at 05:57:40PM +0100, Daniel Vetter wrote:
@@ -230,23 +272,23 @@ static inline u64 drm_mm_hole_node_end(const struct drm_mm_node *hole_node)
/**
- drm_mm_for_each_node - iterator to walk over all allocated nodes
- @entry: drm_mm_node structure to assign to in each iteration step
- @mm: drm_mm allocator to walk
- @entry: &drm_mm_node structure to assign to in each iteration step
If we have the &struct link, do we need to say "structure"? We use a mix of "&struct structure" and plain "&struct". Choose a style and make it consistent. (Bonus points for an easy to find style guide.)
There's also "struct &struct_name" and "&struct struct_name". Anything goes really, and I just semi-randomly pick what reads reasonably well. The issue with macros is that they don't have the types in the declaration (compared to functions), that's why I added the &.
And I think indicating the text that it's a structure makes some sense, since the link could also be to an enum.
Does "&struct struct_name" render well in the html? I think that's the easiest style for us to remember since it matches C (and so also reads well for someone versed in C).
Anyway if you insist I can do some ocd for drm_mm, but for all of the drm docs is a bit much.
I don't insist, I just think having a recommended way of writing the stanzas not only reduce the cognitive burden of writing them but also reading them.
Hm ok, quick counting shows that &struct foo seems to win. I'll make a patch as the canonical thing.
Oh and the style guides we have: https://dri.freedesktop.org/docs/drm/doc-guide/sphinx.html#writing-documenta... https://dri.freedesktop.org/docs/drm/gpu/introduction.html#style-guidelines
I said easy to find! :) Something like Documentation/WritingStyle
Documentation/doc-guide as a directory to find it all. And there's links to it at a growing set of places ... -Daniel