linux-kernel - Re: [PATCH 00/86] PATA fixes

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4B18376B.3080404@garzik.org>
Date:	Thu, 03 Dec 2009 17:10:51 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-ide@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/86] PATA fixes

On 12/03/2009 05:06 PM, Bartlomiej Zolnierkiewicz wrote:
> On Thursday 03 December 2009 11:02:36 pm Jeff Garzik wrote:
>> On 12/03/2009 04:56 PM, Bartlomiej Zolnierkiewicz wrote:
>>> On Thursday 03 December 2009 10:51:09 pm Jeff Garzik wrote:
>>>
>>>>>>>           pata_via: clear UDMA transfer mode bit for PIO and MWDMA
>>>>>>
>>>>>> applied -- even though Alan's comment was correct.  It is standard
>>>>>> kernel practice to place cosmetic changes into their own patches,
>>>>>> because it is standard kernel practice to break up logically distinct
>>>>>> changes.
>>>>>
>>>>> We are talking about:
>>>>>
>>>>>     pata_via.c |   19 +++++++++++++------
>>>>>     1 file changed, 13 insertions(+), 6 deletions(-)
>>>>>
>>>>> patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change
>>>>> is clearly documented in the patch description.
>>>>>
>>>>>
>>>>> Do people really wonder why I find upstream to be too much hassle to
>>>>> deal with?
>>>>
>>>> The thousand other kernel developers seem to be able to split up their
>>>> patches, separating out cosmetic changes from functional ones.  It has
>>>> clear engineering benefits, and has been standard practice for a decade
>>>> or more.
>>>>
>>>> Why is it such an imposition for your patches to look like everyone
>>>> else's?  And by "everyone", I mean all other kernel developers, not just
>>>> other ATA developers.
>>>>
>>>> You seem to consider standard kernel practice a hassle.  Separating out
>>>> cosmetic changes is not only a libata practice, it is the norm for the
>>>> entire kernel.
>>>
>>> Indeed.
>>>
>>>   From 94be9a58d7e683ac3c1df1858a17f09ebade8da0 Mon Sep 17 00:00:00 2001
>>> From: Jeff Garzik<jeff@...zik.org>
>>> Date: Fri, 16 Jan 2009 10:17:09 -0500
>>> Subject: [PATCH] [libata] get-identity ioctl: Fix use of invalid memory pointer
>>>    for SAS drivers.
>>>
>>> Caught by Ke Wei (and team?) at Marvell.
>>>
>>> Also, move the ata_scsi_ioctl export to libata-scsi.c, as that seems to be the
>>> general trend.
>>>
>>> Acked-by: James Bottomley<James.Bottomley@...senPartnership.com>
>>> Signed-off-by: Jeff Garzik<jgarzik@...hat.com>
>>
>> If your point, by posting this patch, is that it includes a ton of
>> gratuitous cosmetic changes, you misread the patch.
>>
>> ata_scsi_ioctl() remains in existence; only the callers need to use the
>> new SAS-related ioctl function were updated.  The remainder continued to
>> use ata_scsi_ioctl().
>
> Moving kernel exports around is completely unrelated to a bug fix.

Did the patch contain -cosmetic- changes intermingled with code changes, 
in the same code lines?  No.

Is it good kernel practice to intermingle cosmetic changes with 
functional ones, in the same code lines?  Also, no.

	Jeff



--
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/