Live data from Hacker News

The Problem with Linux Kernel Documentation, and How We're Fixing It

blogs.s-osg.org

11–20 of 34 posts

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#11

They missed a format that's ubiquitous, has a lot of formatting options, and has search facilities. Manpages. When someone's looking for a piece of documentation, they are usually working on a system as they do it, and man -k is a lot easier to remember than some other search tool that requires its own set of packages, etc.

Nothing prevents their new solution from generating man pages as a way to create end user accessible documents.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#12
post #6
post #4

Earlier quoted context omitted.

Depends. We use Markdown pretty extensively and the drawbacks listed on the site don't really apply - you can always either: 1. Embed HTML (more or less preferred, depending on your situation). 2. Create an extension.

>Embed HTML (more or less preferred, depending on your situation) But then you can't embed markdown inside the HTML, like code blocks inside a table. Sure you can use tags, but then you lose syntax highlighting. Actually I've always wondered why no MD renderer supports something like which it then treats the same as a ```js code block. Or a pseudo element...

Kramdown supports this with markdown="1" as an attribute on html tags: http://kramdown.gettalong.org/syntax.html#html-blocks

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#13
post #10

Earlier quoted context omitted.

Perhaps there's little documentation _because_ it has a poor format.

Not because of Programmers who think that the time spent writing documentation would be better spent programming some more? ;)

No reason it couldn't be both, I suppose.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#14
post #10

Earlier quoted context omitted.

Not because of Programmers who think that the time spent writing documentation would be better spent programming some more? ;)

No reason it couldn't be both, I suppose.

Definitely the case in my office. A couple of opinionated and (relatively) senior devs that think the code is the documentation. No, I can't read this 40 yo fortran code and use it as the basis for a new program on a different architecture. It uses gotos and variables like "yxtgn" that mean nothing to the reader (turned out y meant it was an integer, weird). I spent a month on that because there was no documentation, which took up a page once I was done writing it after my reverse engineering effort.

And then documentation, where it exists, is often poorly CM'd word documents, and poorly OCR'd PDFs (or doc->pdf that somehow lost the ability to be searchable and selectable text, what option did they select?!?).

The offending systems are only maintainable because a few people haven't retired (< 1 year left for several of them) and sheer force of will for the rest of us.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#15

They missed a format that's ubiquitous, has a lot of formatting options, and has search facilities. Manpages. When someone's looking for a piece of documentation, they are usually working on a system as they do it, and man -k is a lot easier to remember than some other search tool that requires its own set of packages, etc.

Manpages are not a format to write the documentation, but to display it.

You can `make mandocs` in the linux tree, then `make installmandocs` to make them easily accessible with the man command, i.e. `man struct_sk_buff` will display the definition of an sk_buff.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#16
post #4
post #2

Happy to see they pick ReST over MD. ReST is vastly superior for these purposes, in my experience.

Depends. We use Markdown pretty extensively and the drawbacks listed on the site don't really apply - you can always either: 1. Embed HTML (more or less preferred, depending on your situation). 2. Create an extension.

3. Pick a language that already supports it and is stable, standardized, without having to whip out some specialized version just for your codebase.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#17

They missed a format that's ubiquitous, has a lot of formatting options, and has search facilities. Manpages. When someone's looking for a piece of documentation, they are usually working on a system as they do it, and man -k is a lot easier to remember than some other search tool that requires its own set of packages, etc.

The problem with that approach is that you are limiting yourself to fundamentally primitive documentation (and by primitive I mean non-interactive). Granted, for a kernel it might be less important, but it's great when there is a good architecture diagram/image instead of 7 paragraphs.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#18
post #6

Earlier quoted context omitted.

>Embed HTML (more or less preferred, depending on your situation) But then you can't embed markdown inside the HTML, like code blocks inside a table. Sure you can use tags, but then you lose syntax highlighting. Actually I've always wondered why no MD renderer supports something like which it then treats the same as a ```js code block. Or a pseudo element...

Kramdown supports this with markdown="1" as an attribute on html tags: http://kramdown.gettalong.org/syntax.html#html-blocks

Not only are you correct, you allowed me to find an equivalent feature in CommonMark! If there is an empty line between some content and its wrapping HTML tags then that content will be interpreted as markdown. So

    
    
    ```js
    console.log("Hello, world!");
    ```
    
    
will work as expected. http://spec.commonmark.org/0.26/#example-118 and further discussion at http://spec.commonmark.org/0.26/#example-153

VSCode's markdown preview renderer ( https://github.com/markdown-it/markdown-it ) implements CommonMark, so I'm very happy right now :)

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#19
post #6
post #4

Earlier quoted context omitted.

Depends. We use Markdown pretty extensively and the drawbacks listed on the site don't really apply - you can always either: 1. Embed HTML (more or less preferred, depending on your situation). 2. Create an extension.

>Embed HTML (more or less preferred, depending on your situation) But then you can't embed markdown inside the HTML, like code blocks inside a table. Sure you can use tags, but then you lose syntax highlighting. Actually I've always wondered why no MD renderer supports something like which it then treats the same as a ```js code block. Or a pseudo element...

> But then you can't embed markdown inside the HTML, like code blocks inside a table. Sure you can use
 tags, but then you lose syntax highlighting.

Pandoc supports this with the `markdown_in_html_blocks` option.

Re: The Problem with Linux Kernel Documentation, and How We're Fixing It

#20
post #16
post #4

Earlier quoted context omitted.

Depends. We use Markdown pretty extensively and the drawbacks listed on the site don't really apply - you can always either: 1. Embed HTML (more or less preferred, depending on your situation). 2. Create an extension.

3. Pick a language that already supports it and is stable, standardized, without having to whip out some specialized version just for your codebase.

Not like you have to do anything to get it to work OOB, but your mileage may vary. One of the benefits of Markdown is that it's easily understood by people new to the doc space. RST is slightly more complex and has more rules added in.
Post reply on HN