mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heikki Orsila <shdl@zakalwe.fi>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, Andi Kleen <ak@suse.de>
Subject: Re: [PATCH] Improve Documentation/stable_api_nonsense.txt
Date: Tue, 29 Jan 2008 16:14:19 +0200	[thread overview]
Message-ID: <20080129141419.GG12172@zakalwe.fi> (raw)
In-Reply-To: <20080129131500.GA10761@kroah.com>

This is my last counter argument. Based on this I'll submit a new patch
that is less intrusive.

On Tue, Jan 29, 2008 at 05:15:00AM -0800, Greg KH wrote:
> I strongly disagree with this.  If you are reading documentation, you
> should at least be intertained a bit, and if you take the "flavor" of
> the writer out of it entirely, it becomes quite boring and dry.

I hope we agree that by definition the success of documentation is 
measured by its ability to convey ideas. So the basic disagreement is 
"simple English" versus "some flavor of English".
"entertainment value" is there only to keep the person reading, but 
"complicated" sentences harm readability.

> > > > @@ -68,11 +68,11 @@ consider the following facts about the Linux kernel:
> > > >      There is no way that binary drivers from one architecture will run
> > > >      on another architecture properly.
> > > >  
> > > > -Now a number of these issues can be addressed by simply compiling your
> > > > -module for the exact specific kernel configuration, using the same exact
> > > > +Now, a number of these issues can be addressed by simply compiling your
> > > > +module for the same kernel configuration, using the same
> > > 
> > > No, I want to emphasize the word "exact" here.  It has to be the same.
> > 
> > Do you want preserve both "exact specific" and "same exact"?
> 
> Both.
> 
> > Imo,
> > "same exact C compiler" is just bad language, because C compilers are 
> > always "exact". "exactly same C compiler" would do.
> 
> No, "exactly same C compiler" doesn't parse well in English.

"Same exact C compiler" does not mean what you try to say.

> > > >  C compiler that the kernel was built with.  This is sufficient if you
> > > >  want to provide a module for a specific release version of a specific
> > > > -Linux distribution.  But multiply that single build by the number of
> > > > +Linux distribution. However, multiply that single build by the number of
> > > 
> > > You messed with the "two space" rule, and changed the word unecessarily
> > > in my opinion.
> > > 
> > > >  different Linux distributions and the number of different supported
> > > >  releases of the Linux distribution and you quickly have a nightmare of
> > > >  different build options on different releases.  Also realize that each
> > > > @@ -93,7 +93,7 @@ keep a Linux kernel driver that is not in the main kernel tree up to
> > > >  date over time.
> > > >  
> > > >  Linux kernel development is continuous and at a rapid pace, never
> > > > -stopping to slow down.  As such, the kernel developers find bugs in
> > > > +slowing down.  As such, the kernel developers find bugs in
> > > 
> > > No, they never stop, I say leave it as is.
> > 
> > Imo, that statement is very odd. The meaning of it has to be guessed.
> > "never slowing down" is very simple and conveys the essential idea.
> 
> Hm, but you understood the idea conveyed here, right?  That's the
> important issue, we can argue about the exact structure of words all
> day, which will get us no where.

Right, this argument can't continue without other people's perspectives.

> Ok, fair enough, I can agree with that.

Good :)

> > > > @@ -145,6 +145,10 @@ as small as possible, and that all potential interfaces are tested as
> > > >  well as they can be (unused interfaces are pretty much impossible to
> > > >  test for validity.)
> > > >  
> > > > +Some complain that kernel interfaces change too often for out-of-the-tree
> > > > +modules, but this claim is false. Changing an interface can be delicate work,
> > > > +and it can take significant amount of developer effort. Therefore, interfaces
> > > > +are not changed without a good reason.
> > > 
> > > No, their claim is a valid one, it's not "false".  However we are not
> > > going to do anything about it, and as such, we don't need this kind of
> > > wording to get people worried about it even more.
> > 
> > How about this (scrap the whole paragraph):
> > 
> > Changing an interface can be delicate work and it can take significant 
> > amount of developer effort. Therefore, an interface is not changed
> > unless the change is regarded as very important by the developers.
> 
> Why do you feel this paragraph is needed at all?

Some people may feel there is nothing to prevent constant changes. This 
paragraph tries to assure it is not the case. Actually, the whole point 
of this documentation is to comfort others.

PS. Off topic: I think documentation is a very important topic for Linux 
systems in general (there is lot to be improved!). I wonder how many 
bugs in programs could be avoided by writing good man pages. For 
example, many people tend to get select() wrong, and I suspect it's 
partly because the man page is not as good as it could be. An example 
of good man page would Davide Libenzi's epoll that has an FAQ for common 
questions and an example of suggested usage. Good examples drive 
developers for solutions that are known to work in practice.

-- 
Heikki Orsila			Barbie's law:
heikki.orsila@iki.fi		"Math is hard, let's go shopping!"
http://www.iki.fi/shd

  reply	other threads:[~2008-01-29 14:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28 23:09 Heikki Orsila
2008-01-28 23:14 ` Heikki Orsila
2008-01-29  4:48 ` Greg KH
2008-01-29 10:40   ` Heikki Orsila
2008-01-29 13:15     ` Greg KH
2008-01-29 14:14       ` Heikki Orsila [this message]
2008-01-30 19:32         ` Matt Mackall
2008-01-30 19:38           ` Valdis.Kletnieks
2008-01-29  6:28 ` Andi Kleen

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=20080129141419.GG12172@zakalwe.fi \
    --to=shdl@zakalwe.fi \
    --cc=ak@suse.de \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®