From: Jonathan Corbet <corbet@lwn.net>
To: "Joel Nider" <JOELN@il.ibm.com>
Cc: Matthew Wilcox <willy@infradead.org>,
Doug Ledford <dledford@redhat.com>,
Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Mike Rapoport <rppt@linux.ibm.com>
Subject: Re: [PATCH v2 2/2] docs-rst: userspace: update verbs API details
Date: Tue, 15 Jan 2019 11:08:54 -0700 [thread overview]
Message-ID: <20190115110854.63200119@lwn.net> (raw)
In-Reply-To: <OF64BB6EB2.8999493B-ONC2258383.0058B5B7-C2258383.005AA2FD@notes.na.collabserv.com>
On Tue, 15 Jan 2019 18:29:59 +0200
"Joel Nider" <JOELN@il.ibm.com> wrote:
> > I think this is a horrible direction to take. The current document is
> > clearly for _users_. All this documentation you've added is for kernel
> > hackers. It needs to go in a different file, or not be added at all.
> >
> Hmm, that's a bit heavy-handed in my opinion. If you look at what is
> currently under "Userspace API", there are a total of 4 files - not
> exactly what I would call comprehensive documentation of the Linux kernel
> interface.
One has to start somewhere - I'm glad to see you adding to it.
> So the option of not adding more documentation simply because
> it is in the wrong section seems a bit defeatist (I think we can all agree
> more kernel docs is a good thing). So let's assume for the moment that it
> _should_ be added, and that we are discussing _where_.
I think we definitely want to add it.
> Yes, the document I
> am modifying has a bit of a mash of pure userspace API - functions and
> details that application developers must know - and the lower level
> details that are more useful for someone who wishes to extend this
> interface. The existing documentation (specifically unshare) also suffers
> from the same problem. There is a section (7) called "Low Level Design"
> which documents very much the same level of detail as the Infiniband doc,
> so this seems to be at least consistent.
> I think there is a deeper issue - as an application developer, I would
> only look at this kernel documentation as a last resort. #1 is the 'man'
> pages, #2 is web search for an example (I know for many it's the other way
> around). So who really looks at this documentation? I say the vast
> majority is kernel hackers. So yes, this is about the user-facing API, but
> not from the application writer's perspective - it should be about how to
> create a consistent API for users, from the kernel hacker's perspective.
The intent behind the user-space API manual is to document the user-space
API; it's meant to be read by people writing applications and such.
Perhaps they find it with a web search, but it will be there for them, one
hopes, when they want it.
The project of reworking the kernel documentation to be more comprehensive
and more focused on its readers, rather than, as Rob Landley once put it,
"a gigantic mess, currently organized based on where random passers-by put
things down last" is still in an early stage. But that doesn't mean that
we shouldn't try to always move in the right direction. So I agree with
Willy that this particular text is better suited to the driver-API
manual. Even if a bare bit of information on its own there for now, it's
a starting place. Can I ask you to do that, please?
Thanks,
jon
next prev parent reply other threads:[~2019-01-15 18:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-15 10:26 docs-rst: update infiniband uverbs doc Joel Nider
2019-01-15 10:26 ` [PATCH v2 1/2] docs-rst: Convert user verbs doc to rst Joel Nider
2019-01-15 15:14 ` Jason Gunthorpe
2019-01-15 18:02 ` Jonathan Corbet
2019-01-15 20:41 ` Joel Nider
2019-01-15 10:26 ` [PATCH v2 2/2] docs-rst: userspace: update verbs API details Joel Nider
2019-01-15 15:31 ` Matthew Wilcox
2019-01-15 16:29 ` Joel Nider
2019-01-15 18:08 ` Jonathan Corbet [this message]
2019-01-15 20:37 ` Joel Nider
2019-01-15 21:38 ` Jonathan Corbet
2019-01-17 0:06 ` Mike Rapoport
2019-01-17 6:33 ` Joel Nider
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=20190115110854.63200119@lwn.net \
--to=corbet@lwn.net \
--cc=JOELN@il.ibm.com \
--cc=dledford@redhat.com \
--cc=jgg@ziepe.ca \
--cc=leon@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rppt@linux.ibm.com \
--cc=willy@infradead.org \
/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).