public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
	linux-doc@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx <intel-gfx@lists.freedesktop.org>,
	dri-devel@lists.freedesktop.org, "Purushothaman,
	Vijay A" <vijay.a.purushothaman@intel.com>,
	Rob Landley <rob@landley.net>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>,
	Sagar Arun Kamble <sagar.a.kamble@intel.com>
Subject: Re: [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
Date: Sat, 10 May 2014 13:39:37 +0300	[thread overview]
Message-ID: <20140510103937.GC18465@intel.com> (raw)
In-Reply-To: <3136468.2PAlK4Gq8k@avalon>

On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote:
> Hi Sagar,
> 
> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote:
> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote:
> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote:
> > > > On Wed, Mar 5, 2014 at 11:56 AM,  <sagar.a.kamble@intel.com> wrote:
> > > > > +<table border="1" cellpadding="0" cellspacing="0" >
> > > > > +<tbody>
> > > > > +<tr style="font-weight: bold;" >
> > > > > +<td valign="top" >Owner Module/Drivers</td>
> > > > > +<td valign="top" >Group</td>
> > > > > +<td valign="top" >Property Object</td>
> > > > > +<td valign="top" >Property Name</td>
> > > > > +<td valign="top" >Type</td>
> > > > > +<td valign="top" >Property Values</td>
> > > > > +<td valign="top" >Object attached</td>
> > > > > +<td valign="top" >Description</td>
> > > > > +</tr>
> > > > 
> > > > In my opinion this is a horrible way to write property documentations
> > > > - explicitly constructing html tables is error prone and really hard
> > > > to read in the source. Imo docbook in general is rather horrible,
> > > > which is way I write almost all my docs as kerneldoc ;-)
> > > > 
> > > > I think a simple asciidoc/markdown would be much simpler, with a bit
> > > > of free-form structure to group properties into relevant groups.
> > > > Long-term we might even need to split it up into different spec files
> > > > to keep a good overview.
> > > 
> > > Docbook is indeed hard to read and write when it comes to such tables.
> > > However I like having the properties documented in the DRM core
> > > documentation. Maybe we could come up with a simpler text format that
> > > would be transformed into docbook when compiling the documentation ?
> > 
> > Does this mean we need to create comment block with "Doc: drm
> > properties" style section in each driver where drm properties are
> > instantiated. And then in drm.tmpl collect all these using !P escape
> > sequence?
> > How do create table out of these across all drivers?
> 
> I don't have a strong preference here. Documenting properties in source code 
> comments would be fine, so would an external central documentation file in a 
> non Docbook format. For the record I'm personally fine with using Docbook as 
> in this patch :-)
> 
> If we decide to go for property documentation inside the source code then I 
> believe we'll have to create our own format, as creating a properties table 
> from kerneldoc information extracted from comments is probably not possible.

Can comeone pick up the ball here and figure out what needs to be done?

The reason why I want a central place for the documentation is to force
people to collaborate outside their own sandbox when adding properties.
Whether that's docbook or some text file I don't care so much at this
point. The fact that it's a central place should mandate that the
patches changing it will go through dri-devel and so everyone should se
them, and when adding new properties it would make the patch author more
likely to look around a bit before adding another slighty incompatible
version of the same property. If someone has a better suggestion how to
encforce this I'm all ears.

Of course this idea can still fail if our esteemed maintainer merges
stuff without checking for violations of this policy. Dave, any thoughts
on the subject?

Either way I can tell you that I'm not very enthusiastic about reviewing
any property patches until some kind of decision about this is reached,
be it "docbook", "text", "plan c", or "fuck it, let the world burn!".

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2014-05-10 10:39 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-05 10:56 [PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers sagar.a.kamble
2014-03-06  7:15 ` [PATCH v2 " sagar.a.kamble
2014-03-06 12:09   ` Ville Syrjälä
2014-03-06 14:01     ` Sagar Arun Kamble
2014-03-06 14:27       ` [PATCH v3 " sagar.a.kamble
2014-03-07 18:44         ` Randy Dunlap
2014-03-08  6:33         ` [PATCH v4 " sagar.a.kamble
2014-03-08  7:28           ` [PATCH v5 " sagar.a.kamble
2014-03-10 14:33             ` Laurent Pinchart
2014-03-11 10:37               ` [PATCH v6 " sagar.a.kamble
2014-03-11 11:22                 ` Laurent Pinchart
2014-03-11 14:25                   ` [PATCH v7 " sagar.a.kamble
2014-03-11 14:31                     ` Laurent Pinchart
2014-03-11 13:13                 ` [PATCH v6 " Deucher, Alexander
2014-03-11 14:07                   ` Sagar Arun Kamble
2014-03-06 14:41       ` [PATCH v3 " sagar.a.kamble
2014-03-10  5:21 ` [PATCH " Daniel Vetter
2014-03-10 14:36   ` Laurent Pinchart
2014-03-12 11:16     ` Sagar Arun Kamble
2014-03-12 11:25       ` Laurent Pinchart
2014-05-10 10:39         ` Ville Syrjälä [this message]
2014-05-10 10:56           ` Rob Clark
2014-05-12  6:07             ` Sagar Arun Kamble
2014-05-12  8:03               ` Daniel Vetter
2014-05-13  7:17                 ` Thierry Reding
2014-05-13  7:34                   ` Daniel Vetter
2014-05-13  9:05                     ` Thierry Reding
2014-05-13 11:02                     ` Laurent Pinchart
2014-05-13 11:51                       ` Daniel Vetter
2014-05-12  8:24           ` Dave Airlie
2014-05-12  8:58             ` Daniel Vetter
2014-05-12 15:23               ` Randy Dunlap
2014-05-12 15:54                 ` Daniel Vetter
2014-05-12 18:04                   ` Randy Dunlap
2014-07-31 22:16                     ` Randy Dunlap
2014-08-01 12:58                       ` Laurent Pinchart
2014-08-01 22:21                         ` Randy Dunlap
2014-08-04  7:30                         ` Daniel Vetter
2014-08-04 13:58                           ` Laurent Pinchart

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=20140510103937.GC18465@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=laurent.pinchart+renesas@ideasonboard.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=rob@landley.net \
    --cc=sagar.a.kamble@intel.com \
    --cc=vijay.a.purushothaman@intel.com \
    /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