From: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: Dan Carpenter <dan.carpenter@oracle.com>,
ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [CORE-TOPIC] Documentation
Date: Tue, 14 Jul 2015 09:43:42 -0300 [thread overview]
Message-ID: <20150714094342.36be30fe@recife.lan> (raw)
In-Reply-To: <20150713203647.1fdb8bb4@lwn.net>
Em Mon, 13 Jul 2015 20:36:47 -0600
Jonathan Corbet <corbet@lwn.net> escreveu:
> > Would doxygen be "something better"? The kernel-doc style looks already quite
> > similar.
> > Maybe the kernel should not reinvent everything :)
My experience is that, from time to time, people send us drivers written
by the manufacturer with Doxygen-compatible tags. Converting them to
kernel-doc is a huge task, not worthing the effort. I tried in the past
to request developers to "fix" the comments. The net result is either
to not have a final version of the driver submitted or to receive a
comments-stripped version of it, with is actually worse, as we loose
lots of otherwise good documentation. So, nowadays, I'm opting to keep
whatever comments are there at the code, provided that it is not using
C99 comments.
So, I'm a huge fan of extending the kernel-doc to accept all markup tags
that Doxygen supports.
> Doxygen may be worth a look. I'm personally fond of Sphinx, though I
> still haven't done a big project in it.
I never used Sphinx. Doxygen seems better on my eyes, because people
already sends us media drivers using Doxygen tags style. Also, as
mentioned, kernel-doc style is a subset. Not to mention that, in the
specific case of media,we're using Doxygen to document some libraries
packaged inside v4l-utils (with is the userspace counterpart of the
Kernel subsystem). So, at least for me, Doxygen would be easier to use.
Regards,
Mauro
next prev parent reply other threads:[~2015-07-14 12:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-12 22:38 Peter Hüwe
2015-07-12 23:15 ` Julia Lawall
2015-07-14 11:59 ` Mauro Carvalho Chehab
2015-07-13 9:47 ` Alexey Dobriyan
2015-07-13 16:01 ` Randy Dunlap
2015-07-13 16:37 ` Steven Rostedt
2015-07-13 16:46 ` David Woodhouse
2015-07-13 17:35 ` Steven Rostedt
2015-07-13 19:22 ` Peter Hüwe
2015-07-13 19:28 ` Peter Hüwe
2015-07-13 17:42 ` Jason Cooper
2015-07-13 18:11 ` Steven Rostedt
2015-07-14 3:56 ` Zefan Li
2015-07-13 19:25 ` Peter Hüwe
2015-07-13 22:10 ` Laurent Pinchart
2015-07-13 17:45 ` Jonathan Corbet
2015-07-13 19:46 ` Peter Hüwe
2015-07-14 2:36 ` Jonathan Corbet
2015-07-14 8:40 ` Laurent Pinchart
2015-07-14 11:19 ` Daniel Vetter
2015-07-14 12:43 ` Mauro Carvalho Chehab [this message]
2015-07-14 12:53 ` Jonathan Corbet
2015-07-14 13:57 ` Laurent Pinchart
2015-07-14 6:44 ` Johannes Berg
2015-07-13 19:20 ` Peter Hüwe
2015-07-13 23:01 ` Laurent Pinchart
2015-07-13 17:05 ` Lai Jiangshan
2015-07-13 17:42 ` Jonathan Corbet
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=20150714094342.36be30fe@recife.lan \
--to=mchehab@osg.samsung.com \
--cc=corbet@lwn.net \
--cc=dan.carpenter@oracle.com \
--cc=ksummit-discuss@lists.linuxfoundation.org \
/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