From: Thierry Reding <thierry.reding@gmail.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [RFC] drm: Start documenting userspace ABI
Date: Tue, 18 Nov 2014 15:43:43 +0100 [thread overview]
Message-ID: <20141118144006.GA18586@ulmo> (raw)
In-Reply-To: <20141118142727.GD25711@phenom.ffwll.local>
[-- Attachment #1.1: Type: text/plain, Size: 2121 bytes --]
On Tue, Nov 18, 2014 at 03:27:27PM +0100, Daniel Vetter wrote:
> On Tue, Nov 18, 2014 at 03:19:33PM +0100, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > After seeing how the DRM_IOCTL_MODE_CREATE_DUMB was implemented with
> > different semantics on different drivers it seems like a good idea to
> > start to more rigorously document userspace ABI to avoid these things
> > in the future.
> >
> > This is a first draft of what such documentation could look like. Not
> > all IOCTLs are documented and some explanation about the other system
> > calls (mmap(), poll(), read(), ...) would be good too. But I wanted to
> > send this out for early review to see if the direction is reasonable.
> > If so my plan is to continue to chip away at this as I find time.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> Imo for ioctls the right thing to do is having proper manpages, not
> kerneldoc or DocBook sections. manpages really lend themselves well to
> specify all the different facets of a single interface.
I don't think I've ever seen manpages document IOCTLs at this level of
detail. The intention of this is to add documentation about the IOCTLs
at the kernel/userspace transition. Keeping this in the kernel has the
advantage that it's a whole lot easier to keep updated, much like what
we do with the other kerneldoc.
That doesn't mean we shouldn't have manpages, but I think both are for
the most part orthogonal, even though they may describe various facets
of the same interfaces.
> Also, we already have some skeleton of that in libdrm, so I think
> extending that would be best.
One other reason why I don't think libdrm is the best fit for this is
that libdrm is just one userspace implementation abstracting away the
interfaces that this describes. Not everyone will use libdrm. So in my
opinion its great if libdrm documents the API that it exposes, but I
don't think it should document the kernel interfaces that it uses. The
kernel exposes them, so it should provide the documentation for it as
well.
Thierry
[-- Attachment #1.2: Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-11-18 14:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-18 14:19 [RFC] drm: Start documenting userspace ABI Thierry Reding
2014-11-18 14:27 ` Daniel Vetter
2014-11-18 14:43 ` Thierry Reding [this message]
2014-11-18 15:05 ` David Herrmann
2014-11-18 15:24 ` Thierry Reding
2014-11-19 13:23 ` Daniel Vetter
2014-12-01 1:32 ` 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=20141118144006.GA18586@ulmo \
--to=thierry.reding@gmail.com \
--cc=daniel.vetter@ffwll.ch \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart+renesas@ideasonboard.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.