LKML Archive on
help / color / mirror / Atom feed
From: "Michael Kerrisk" <>
To: "Ulrich Drepper" <>
Subject: Re: [PATCH] cleanup paccept
Date: Tue, 28 Oct 2008 15:10:44 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Oct 28, 2008 at 2:09 PM, Ulrich Drepper <> wrote:
> This patch doesn't change *any* functionality from what is currently
> in the upstream kernel.  There is no reason to start arguing again and
> for me to explain everything the way I did it months ago.  This is just
> a *cleanup patch*, nothing else.  If you want to know why this cleanup
> is needed read the discussions of
> commit 2d4c8266774188cda7f7e612e6dfb8ad12c579d5
> Author: Michael Kerrisk <>
> Date:   Mon Sep 22 13:57:49 2008 -0700
>    sys_paccept: disable paccept() until API design is resolved
> For example, here:
> I don't agree with the change but I'm also tired arguing.  So just
> clean up the mess created by change initiated by the posting mentioned
> above.

Oh, please!  The "mess" arose because you refused to explain things in
a simple and coherent fashion, even when politely asked.

And now you compound the mess by running up two threads in the last 24
hours with versions of the patch (are they the same -- who knows?  You
give us no clue.)  So I'll repeat here, what I said in the other:

1. Please take the trouble to CC interested parties.  For example, the
people CCed in recent threads that discussed earlier versions of the
the patch.  This is basic LKML basic etiquette, since almost no one
reads all LKML, nor reads it hourly.  Doing this allows interested
parties to comment on the patch, and also avoids patches hitting the
kernel "under the radar".

2. Don't assume anyone has cached earlier discussions of the topic.
Write a clear, complete description of the patch that could be read by
someone new to the topic, something like a summary of and

[If you had done this the first time round, then there'd be very
little work other than cut and paste this time round.]

3. Explain what changes have been made from earlier versions of the
patch, and why.
E.g., some discussion that summarizes this:

4. CC on patches that are API changes.  This
requirement was added to SubmitChecklist in the last few weeks.

5. CC me or, so that something makes its way
into man-pages.

> The actual patch which is in the kernel is different from
> the patch in the mail: only the signal mask handling has been disabled.
> This is why this is only a cleanup patch.

And that does not explain to the world at large what this
to-be-enabled system call does, or why it's needed.



  parent reply	other threads:[~2008-10-28 20:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-28 19:09 Ulrich Drepper
2008-10-28 19:15 ` Christoph Hellwig
2008-10-28 19:17 ` Linus Torvalds
2008-10-28 20:10 ` Michael Kerrisk [this message]
2008-10-28 20:20   ` Michael Kerrisk

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: [PATCH] cleanup paccept' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).