linux-kernel - Re: [PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAKMK7uFMDcwk=ovX9+_R4FBOx6=sYnaOZwHuHSdQixdk-5_hwg@mail.gmail.com>
Date:   Tue, 23 Aug 2016 15:28:55 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Jonathan Corbet <corbet@....net>
Cc:     Mauro Carvalho Chehab <mchehab@...pensource.com>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Markus Heiser <markus.heiser@...marit.de>,
        linux-doc@...r.kernel.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        "linaro-mm-sig@...ts.linaro.org" <linaro-mm-sig@...ts.linaro.org>,
        "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] Documentation/sphinx: link dma-buf rsts

On Tue, Aug 23, 2016 at 3:08 PM, Jonathan Corbet <corbet@....net> wrote:
> On Tue, 23 Aug 2016 08:01:35 +0200
> Daniel Vetter <daniel@...ll.ch> wrote:
>
>> I'm also not too sure about whether dma-buf really should be it's own
>> subdirectory. It's plucked from the device-drivers.tmpl, I think an
>> overall device-drivers/ for all the misc subsystems and support code would
>> be better. Then one toc there, which fans out to either kernel-doc and
>> overview docs.
>
> I'm quite convinced it shouldn't be.
>
> If you get a chance, could you have a look at the "RFC: The beginning of
> a proper driver-api book" series I posted yesterday (yes, I should have
> copied more of you, sorry)?  It shows the direction I would like to go
> with driver API documentation, and, assuming we go that way, I'd like the
> dma-buf documentation to fit into that.

Looks real pretty, ack on that. And we can always split up more, e.g.
by extracting dma-buf.rst (and merg the current dma-buffer-sharing.txt
into that one).

I think the more interesting story is, what's your plan with all the
other driver related subsystem? Especially the ones which already have
full directories of their own, like e.g. Documentation/gpio/. I think
those should be really part of the infrastructure section (or
something equally high-level), together with other awesome servies
like pwm, regman, irqchip, ... And then there's also the large-scale
subsystems like media or gpu. What's the plan to tie them all
together? Personally I'm leaning towards keeping the existing
directories (where they exist already), but inserting links into the
overall driver-api section.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch