linux-kernel - Re: [PATCH] cleanup paccept

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 28 Oct 2008 15:10:44 -0500
From:	"Michael Kerrisk" <mtk.manpages@...il.com>
To:	"Ulrich Drepper" <drepper@...hat.com>
Cc:	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	linux-api@...r.kernel.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] cleanup paccept

On Tue, Oct 28, 2008 at 2:09 PM, Ulrich Drepper <drepper@...hat.com> 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 <mtk.manpages@...glemail.com>
> Date:   Mon Sep 22 13:57:49 2008 -0700
>
>    sys_paccept: disable paccept() until API design is resolved
>
>
> For example, here:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2008/9/16/3310534
>
>
> 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
http://lwn.net/Articles/281965/ and http://udrepper.livejournal.com/20407.html

[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:
http://thread.gmane.org/gmane.linux.network/106071

4. CC linux-api@...r.kernel.org on patches that are API changes.  This
requirement was added to SubmitChecklist in the last few weeks.

5. CC me or linux-man@...r.kernel.org, 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.

Cheers,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/