On Tue, Aug 23, 2016 at 3:08 PM, Jonathan Corbet <corbet@xxxxxxx> wrote: > On Tue, 23 Aug 2016 08:01:35 +0200 > Daniel Vetter <daniel@xxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
