On Fri, Jun 4, 2021 at 2:19 PM Grant Seltzer Richman <grantseltzer@xxxxxxxxx> wrote: > > On Tue, Jun 1, 2021 at 9:06 PM Grant Seltzer Richman > <grantseltzer@xxxxxxxxx> wrote: > > > > On Tue, Jun 1, 2021 at 7:19 PM Jonathan Corbet <corbet@xxxxxxx> wrote: > > > > > > Grant Seltzer Richman <grantseltzer@xxxxxxxxx> writes: > > > > > > > Andrii cuts releases of libbpf using the github mirror at > > > > github.com/libbpf/libbpf. There's more context in the README there, > > > > but most of the major distributions package libbpf from this mirror. > > > > Since developers that use libbpf in their applications include libbpf > > > > based on these github releases instead of versions of Linux (i.e. I > > > > use libbpf 0.4, not libbpf from linux 5.14), it's important to have > > > > the API documentation be labeled by the github release versions. Is > > > > there any mechanism in the kernel docs that would allow us to do that? > > > > Would it make more sense for the libbpf community to maintain their > > > > own documentation system/website for this purpose? > > > > > > It depends on how you want that labeling to look, I guess. One simple > > > thing might be to put a DOC: block into the libbpf code that holds the > > > version number, then use a kernel-doc directive to pull it in in the > > > appropriate place. Alternatives might include adding a bit of magic to > > > Documentation/conf.py to fetch a "#define VERSION# out of the source > > > somewhere and stash the information away. > > > > Gotcha, I will investigate these approaches. Thanks! > > After investigating/attempting these approaches, my opinion is that it > would be better to have a separate libbpf documentation system (sphinx > configuration files). This way we can maintain separate versions of > the documentation for each release/version without having duplicate > pages, and without having to heavily change the kernel docs files to > fit libbpf specific needs. So I assume you looked at the DOC: block that Jonathan suggested above? Can you walk us a bit on how that would look like and why you think it's not going to work? > > If you check out libbpf.readthedocs.io you can see what that would > look like. I made a test release (v21.21.21) to show how easy this is. > That is being pulled from my PR at github.com/libbpf/libbpf/pull/260. It looks pretty nice. Where does v21.21.21 come from, though? It's also weird that docs are under src/docs, not just under docs/, but I assume that's a quick hack to demonstrate this? > > I'm fine with having this new sphinx configuration in the kernel tree, > I'm also fine with having it on the github mirror. Both make sense to > me. Either way the comment docs have to be submitted through the > mailing list. > > One last idea I have is to have the non-api docs (for example, the > document describing naming convention in libbpf) in the kernel tree, > and sync it in the github mirror. > > Please feel free to ask questions, I've been thinking a lot about > this! Once we decide on which way to go I can have this up and running > almost immediately. To be entirely honest, I'm already a bit lost on all the possibilities. It would be great if you can summarize what's possible and how it would look like. As a general guidance, I think we should try to keep all the documentation in one place (which means kernel sources, because that's where API documentation will have to leave). As for config files, unless they will "stick out" too much, I'd keep them close to the docs themselves. If not, putting them in Github mirror is fine by me as well. Pretty much the only important aspect, from my point of view, is that docs are versioned according to the libbpf version, not kernel version. Otherwise huge confusion will ensue for all the users of libbpf, most of not all of which are using Github mirror. Does this make sense and is doable? > > > > > > If you're wanting to replace the version code that appears at the top of > > > the left column in the HTML output, though, it's going to be a bit > > > harder. I don't doubt we can do it, but it may require messing around > > > with template files and such. > > > > > > Thanks, > > > > > > jon
