linux-kernel - Re: [PATCH 01/29] memstick: core: header cleanups

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, 26 Oct 2010 03:10:57 +0200
From:	Maxim Levitsky <maximlevitsky@...il.com>
To:	Alex Dubov <oakad@...oo.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Maxim Levitsky <maximlevitky@...il.com>
Subject: Re: [PATCH 01/29] memstick: core: header cleanups

On Mon, 2010-10-25 at 07:44 -0700, Alex Dubov wrote:
> --- On Fri, 22/10/10, Maxim Levitsky <maximlevitsky@...il.com> wrote:
> 
> > Received: Friday, 22 October, 2010, 4:53 PM
> > * Replace the __attribute__((packed))
> > with __packed
> 
> This introduces unnecessary noise and can be merged into a common clean-up
> patch.
And what value will that add?

> 
> > * Add struct mspro_cmdex_argument, argument for
> > MS_TPC_EX_SET_CMD
> > * Increase size of inline buffer in memstick_request to 32
> > because thats the size of registers and someone might need
> > to read them
> > all. That structure is allocated one per memstick host, so
> > its size
> > doesn't matter.
> 
> This functional changes are better be joined with the first patch which
> actually requires them (these are just 4 lines).
Not fully against that, but then what value will that add too?
Currently memstick.h host many unused structures for MS IO stuff.
And for god's sake it has MS_TPC_EX_SET_CMD declared,
so I just add the structure for its argument, whats wrong with doing
that here?

> 
> > 
> > * Add comments about few members of memstick_request
> 
> Belongs to the clean-up or a separate commenting patch.
Why?

As long as the patch is crearly readable I don't see a reason to add
more patches.


Best regards,
	Maxim Levitsky

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