linux-kernel - Re: Proposed change to mtd read functions (Was Re: [PATCH v2 07/16] mtd/docg3: add OOB layout to mtdinfo)

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] [day] [month] [year] [list]

Message-ID: <1321292344.24797.57.camel@sauron.fi.intel.com>
Date:	Mon, 14 Nov 2011 19:38:53 +0200
From:	Artem Bityutskiy <dedekind1@...il.com>
To:	Mike Dunn <mikedunn@...sguy.com>
Cc:	David Woodhouse <dwmw2@...radead.org>,
	Ivan Djelic <ivan.djelic@...rot.com>,
	Robert Jarzmik <robert.jarzmik@...e.fr>,
	linux-kernel@...r.kernel.org, linux-mtd@...ts.infradead.org
Subject: Re: Proposed change to mtd read functions (Was Re: [PATCH v2 07/16]
 mtd/docg3: add OOB layout to mtdinfo)

On Mon, 2011-11-14 at 10:08 -0800, Mike Dunn wrote:
> This would be better than the cumulative error count over the entire block,
> because the highest count on any one page is more significant, I think.

Yeah, although in the previous proposal I also assumed something like
that, not "cumulative".

Just a side note - take my suggestions with a grain of salt - I do not
actively work on MTD any longer so may mislead you :-)

> >  So the SW which does not care, will not
> > require any changes.
> >
> > I am not sure if you'll need to mtd interfaces from mtd->func(...) to
> > mtd_func(mtd, ...) for this or not, though.
> 
> 
> I don't (yet) see why I would need to. 
> 
> Just adding the argument to mtd->read(), mtd->read_oob(),  would be a simple
> change, but large in scope, affecting all users of the mtd interface.  Any
> advice on how to proceed?

Add the argument without implementing its support, amend all users and
make them compile.

>   Should it be one big patchset, with individual
> patches for changes to mtd, nand, one_nand, mtdchar, each driver, ... ?
>   If it
> is not all merged at once, the build will be broken for the unpatched
> components.  Or is that acceptable, and the patches can be submitted piecemeal,
> starting with, say, mtd, nand, nandsim, mtdram, mtdchar?  Or should we
> temporarily create a branch from l2-mtd until we're satisfiled that this is all
> stable?

We can create a branch regardless, if you find this useful.

I guess one big patch should be OK. If it causes issues we can later
think how to split it.

-- 
Best Regards,
Artem Bityutskiy

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)