public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] KernelDoc
Date: Thu, 27 Sep 2012 01:39:47 +0200	[thread overview]
Message-ID: <201209270139.47165.marex@denx.de> (raw)
In-Reply-To: <50635E42.2040808@ti.com>

Dear Tom Rini,

> On 09/26/12 12:10, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On Tue, Sep 25, 2012 at 10:46:10PM +0200, Marek Vasut wrote:
> >>> Hi all!
> >>> 
> >>> I've had a discussion with Wolfgang just now about U-Boot
> >>> coding style. I tried using KernelDoc in a patch, which is not
> >>> part of the U-Boot Coding Style now, thus it was rejected.
> >>> 
> >>> I really like the idea of annotating functions with proper
> >>> description, thus I would like to ask, can we reach a general
> >>> agreement and start using kerneldoc in U-Boot to annotate
> >>> functions and possibly generate documentation? Or shall we use
> >>> anything else?
> >>> 
> >>> Or any other annotation stuff? Doxygen style? Shall it be
> >>> optional or mandatory?
> >> 
> >> The biggest problem I see with re-using kernel-style doc is that
> >> for the subsytems we sync with the kernel we've probably got
> >> incorrect documentation due to what we stub out and so forth.
> > 
> > +1, but then the creator of the patch is responsible for keeping
> > the docs inline.
> 
> Which will in turn make a mess for further re-syncs.  This should
> probably just be dealt with in the tmpl file for whatever reads the
> drivers/mtd/nand files.
> 
> >> That said, we can somewhat deal with this when we add the tmpl
> >> file that makes the actual output.
> > 
> > Uh, can you elaborate please?
> 
> How familiar with kerneldoc are you?  Yes, you put specially formatted
> comments into source files.  But you also write a tmpl file (see
> Documentation/DocBook/kgdb.tmpl for example) that references the code
> and further elaborates on things and so on.
> 
> >> I think the first and most important step is to document the code
> >> that comes in and isn't trivial.
> > 
> > +1
> > 
> >> If DM is going to do kernel-doc style comments, good.
> > 
> > Not only DM please.
> 
> Yes, I'm just using this as an example.
> 
> >> But we need to borrow the Documentation/DocBook Makefile and
> >> logic and so on from the kernel first.  And add template files
> >> for the DM sections so something can be spit out.
> > 
> > I'd leave that for step 2 (documentation generation) and don't
> > bother with this right away.
> 
> No.  In order for everyone who isn't on your team to understand what
> you're doing, documentation is needed.  And I know you already agree
> here.  What I'm saying is that instead of for example a static
> doc/driver-model/UDM-serial.txt we would move to having
> doc/DocBook/UDM-serial.tmpl which would cover the same content as the
> current file, reference the code in question and if A and B get out of
> sync, well, this is something you and your team should check before
> posting.  Making sure you document what you code AND code what you
> document is important.

Yes, I agree. We will need a code documentation anyway, so I might as well 
invest time into this.

Best regards,
Marek Vasut

  reply	other threads:[~2012-09-26 23:39 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-25 20:46 [U-Boot] KernelDoc Marek Vasut
2012-09-26  6:50 ` Prabhakar Lad
2012-09-26  7:12   ` Wolfgang Denk
2012-09-26  7:23     ` Prabhakar Lad
2012-09-26 10:07       ` Wolfgang Denk
2012-09-26  7:17 ` Wolfgang Denk
2012-09-26 15:26   ` Marek Vasut
2012-09-26 18:50     ` Joe Hershberger
2012-09-26 19:05       ` Marek Vasut
2012-09-26 19:54     ` Wolfgang Denk
2012-09-26 19:58       ` Marek Vasut
2012-09-26 20:57         ` Wolfgang Denk
2012-09-26 21:31           ` Tom Rini
2012-09-26 23:38           ` Marek Vasut
2012-10-01  8:54             ` Wolfgang Denk
2012-10-01  9:07               ` Marek Vasut
2012-10-01 10:35                 ` Wolfgang Denk
2012-10-01 10:37                   ` Marek Vasut
2012-10-09 22:49                     ` Tom Rini
2012-10-09 23:35                       ` Marek Vasut
2012-10-14 20:26                       ` Marek Vasut
2012-09-26 20:00       ` Tom Rini
2012-09-27  6:19       ` Stefan Roese
2012-09-27 17:26         ` Tom Rini
2012-09-27 17:28         ` Fabio Estevam
2012-09-27 23:50         ` Graeme Russ
2012-09-28  0:28           ` Marek Vasut
2012-09-28  0:28     ` Scott Wood
2012-09-28  0:44       ` Marek Vasut
2012-09-26 19:05 ` Tom Rini
2012-09-26 19:10   ` Marek Vasut
2012-09-26 19:46     ` Wolfgang Denk
2012-09-26 19:54       ` Marek Vasut
2012-09-26 20:49         ` Wolfgang Denk
2012-09-26 23:36           ` Marek Vasut
2012-09-26 19:57     ` Tom Rini
2012-09-26 23:39       ` Marek Vasut [this message]
2012-09-28 19:48 ` Marek Vasut

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=201209270139.47165.marex@denx.de \
    --to=marex@denx.de \
    --cc=u-boot@lists.denx.de \
    /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