From: Daniel Vetter <daniel@ffwll.ch>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Jonathan Corbet <corbet@lwn.net>,
Linux Doc Mailing List <linux-doc@vger.kernel.org>,
Mauro Carvalho Chehab <mchehab@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
Maxime Ripard <maxime.ripard@bootlin.com>,
Sean Paul <sean@poorly.run>, David Airlie <airlied@linux.ie>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v3 33/33] docs: EDID/HOWTO.txt: convert it and rename to howto.rst
Date: Wed, 12 Jun 2019 21:45:15 +0200 [thread overview]
Message-ID: <CAKMK7uFhPKbpQj1Y2+C1zW0SdRcezHYDA4h=Ri_eV2xB7HtVig@mail.gmail.com> (raw)
In-Reply-To: <20190612144015.033247db@coco.lan>
On Wed, Jun 12, 2019 at 7:40 PM Mauro Carvalho Chehab
<mchehab+samsung@kernel.org> wrote:
>
> Em Tue, 11 Jun 2019 09:37:01 -0600
> Jonathan Corbet <corbet@lwn.net> escreveu:
>
> > On Tue, 11 Jun 2019 06:02:15 -0300
> > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> wrote:
> >
> > > Jon, please correct me if I' wrong, bu I guess the plan is to place them
> > > somewhere under Documentation/admin-guide/.
> >
> > That makes sense to me.
> >
> > > If so, perhaps creating a Documentation/admin-guide/drm dir there and
> > > place docs like EDID/HOWTO.txt, svga.txt, etc would work.
> >
> > Maybe "graphics" or "display" rather than "drm", which may not entirely
> > applicable to all of those docs or as familiar to all admins?
>
> It is up to Daniel/David to decide. Personally, I agree with you that
> either "graphics" or "display" would be better at the admin guide.
We use Documentation/gpu already for the developer guide, I think
going with "gpu" on the admin guide for consistency would be good. I
do personally think that splitting out the admin guide makes sense, we
could also put some recommendations about access rights for drm device
nodes and stuff like that in there.
> > > Btw, that's one of the reasons[1] why I opted to keep the files where they
> > > are: properly organizing the converted documents call for such kind
> > > of discussions. On my experience, discussing names and directory locations
> > > can generate warm discussions and take a lot of time to reach consensus.
> >
> > Moving docs is a pain; my life would certainly be easier if I were happy
> > to just let everything lie where it fell :) But it's far from the hardest
> > problem we solve in kernel development, I assume we can figure it out.
>
> Yeah, it is doable. I'm happy to write the rename patches and even try
> to split some documents at the places I'm more familiar with, but, IMHO,
> we should do some discussions before some of such renames.
>
> For example, Daniel said that:
>
> > > > Yeah atm we're doing a bad job of keeping the kapi and uapi parts
> > > > separate. But the plan at least is to move all the gpu related uapi stuff
> > > > into Documentation/gpu/drm-uapi.rst. Not sure there's value in moving that
> > > > out of the gpu folder ...
>
> From the conversions I've made so far, almost all driver subsystems
> put everything under Documentation/<subsystem: kAPI, uAPI, admin info,
> driver-specific technical info.
>
> It should be doable to place kAPI and uAPI on different books, but there
> will be lots of cross-reference links between them, on properly-written
> docs.
I'm not sure it makes sense to split out the kapi and uapi sides of
the docs complete. For the admin guide I think one overall book
covering all subsystems is good. But someone creating a drm/kms
compositor is not going to be interested much into some special
options for networking protocol I think. For those I think focusing
more on the specific subsystem makes more sense (and easier to share
common concepts/diagrams between uapi and kapi of a given subsystem).
I do think for a given subsystem the uapi side should be clearly split
out (otherwise it's impossible to find for non-kernel people). And
currently drm falls short really badly on this. So maybe a good
argument for a uapi kernel directory would be to force that, but not
sure that's good enough of a reason.
-Daniel
> However, other admin-guide stuff under drivers are usually in the middle
> of the documents. For example, on media, we have some at the uAPI guide,
> like the Device Naming item:
>
> https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/open.html#device-naming
>
> But splitting it from uAPI guide is not an easy task.
>
> At the driver's specific documentation is even messier.
>
> Ok, splitting is doable, but require lots of dedication, and I'm not
> convinced if it would make much difference in practice.
>
> Thanks,
> Mauro
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
next prev parent reply other threads:[~2019-06-12 19:45 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-09 2:26 [PATCH v3 00/33] Convert files to ReST - part 1 Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 01/33] docs: aoe: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 02/33] docs: arm64: convert docs to ReST and rename to .rst Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 03/33] docs: cdrom-standard.tex: convert from LaTeX to ReST Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 04/33] docs: cdrom: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 05/33] docs: cgroup-v1: " Mauro Carvalho Chehab
2019-06-11 19:03 ` Tejun Heo
2019-06-09 2:26 ` [PATCH v3 06/33] docs: cgroup-v1/blkio-controller.rst: add a note about CFQ scheduler Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 07/33] docs: cpu-freq: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 21:38 ` Rafael J. Wysocki
2019-06-10 0:27 ` Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 08/33] docs: " Mauro Carvalho Chehab
2019-06-09 2:26 ` [PATCH v3 09/33] docs: fault-injection: " Mauro Carvalho Chehab
2019-06-10 16:24 ` Federico Vaga
2019-06-09 2:27 ` [PATCH v3 10/33] docs: fb: " Mauro Carvalho Chehab
2019-06-09 7:54 ` Geert Uytterhoeven
2019-06-09 2:27 ` [PATCH v3 11/33] docs: fpga: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 12/33] docs: ide: " Mauro Carvalho Chehab
2019-06-09 7:50 ` Geert Uytterhoeven
2019-06-09 2:27 ` [PATCH v3 13/33] docs: infiniband: " Mauro Carvalho Chehab
2019-06-10 17:27 ` Jason Gunthorpe
2019-06-10 17:35 ` Jonathan Corbet
2019-06-25 13:24 ` Jason Gunthorpe
2019-06-09 2:27 ` [PATCH v3 15/33] docs: kdump: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 16/33] docs: locking: " Mauro Carvalho Chehab
2019-06-10 16:26 ` Federico Vaga
2019-06-09 2:27 ` [PATCH v3 17/33] docs: mic: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 18/33] docs: netlabel: " Mauro Carvalho Chehab
2019-06-12 14:48 ` Paul Moore
2019-06-09 2:27 ` [PATCH v3 19/33] docs: pcmcia: " Mauro Carvalho Chehab
2019-06-09 6:59 ` Dominik Brodowski
2019-06-09 2:27 ` [PATCH v3 20/33] docs: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 21/33] docs: powerpc: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 22/33] docs: pps.txt: convert to ReST and rename to pps.rst Mauro Carvalho Chehab
2019-06-09 9:20 ` Rodolfo Giometti
2019-06-09 2:27 ` [PATCH v3 23/33] docs: ptp.txt: convert to ReST and move to driver-api Mauro Carvalho Chehab
2019-06-09 13:45 ` Richard Cochran
2019-06-09 2:27 ` [PATCH v3 24/33] docs: riscv: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 25/33] docs: Debugging390.txt: convert table to ascii artwork Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 26/33] docs: s390: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 27/33] s390: include/asm/debug.h add kerneldoc markups Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 28/33] docs: target: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 29/33] docs: timers: " Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 30/33] docs: watchdog: " Mauro Carvalho Chehab
2019-06-09 20:51 ` Guenter Roeck
2019-06-09 2:27 ` [PATCH v3 31/33] docs: xilinx: convert eemi.txt to eemi.rst Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 32/33] docs: scheduler: convert docs to ReST and rename to *.rst Mauro Carvalho Chehab
2019-06-09 2:27 ` [PATCH v3 33/33] docs: EDID/HOWTO.txt: convert it and rename to howto.rst Mauro Carvalho Chehab
2019-06-11 8:37 ` Daniel Vetter
2019-06-11 9:02 ` Mauro Carvalho Chehab
2019-06-11 9:40 ` Daniel Vetter
2019-06-11 15:37 ` Jonathan Corbet
2019-06-12 17:40 ` Mauro Carvalho Chehab
2019-06-12 19:45 ` Daniel Vetter [this message]
2019-06-09 9:16 ` [PATCH v3 00/33] Convert files to ReST - part 1 Heiko Carstens
2019-06-09 9:22 ` Markus Heiser
2019-06-09 9:27 ` Heiko Carstens
2019-06-09 12:29 ` Mauro Carvalho Chehab
2019-06-10 15:55 ` Heiko Carstens
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='CAKMK7uFhPKbpQj1Y2+C1zW0SdRcezHYDA4h=Ri_eV2xB7HtVig@mail.gmail.com' \
--to=daniel@ffwll.ch \
--cc=airlied@linux.ie \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=maxime.ripard@bootlin.com \
--cc=mchehab+samsung@kernel.org \
--cc=mchehab@infradead.org \
--cc=sean@poorly.run \
/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;
as well as URLs for NNTP newsgroup(s).