linux-kernel - Re: [PATCH 0/10] Add yaffs2 file system: Fifth patchset

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]

Message-ID: <20110217060800.GA9645@opensource.wolfsonmicro.com>
Date:	Thu, 17 Feb 2011 06:08:02 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Charles Manning <manningc2@...rix.gen.nz>
Cc:	Christoph Hellwig <hch@...radead.org>,
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
	ryan@...ewatersys.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 0/10] Add yaffs2 file system:  Fifth patchset

On Thu, Feb 17, 2011 at 05:22:15PM +1300, Charles Manning wrote:
> On Thursday 17 February 2011 16:49:14 Mark Brown wrote:

> > You're missing the use case here - I'm talking about the situation where
> > you completely ignore the vendor BSP and go direct to mainline without
> > reference to the vendor provided stuff.  The user may not even have the
> > vendor provided BSP to look at.

> I don't understand what problem you are trying to illustrate.

> First off, kernel BSPs should always be available in accordance with the GPL.

Sure, but the effort involved in obtaining them (especially for older
boards) often greatly exceeds the value of looking at them - often it's
much easier to go direct to mainline.

> Secondly the defaults work for just about every case. So long as the mtd has 
> been set up then dropping in yaffs using defaults is generally pretty 
> straight forward and there is no tuning required,

> Some tuning is required if the mtd does not pass through all the info that is 
> required. In the fullness of time I would expect that this info would be 
> provided by mtd.

Your descriptions made it sound like tthis was higher level information
that was being provided.  If it's just fixups to the flash description
then I would expect that the flash driver would handle it as you suggest.

> My point was that the "platform data" -- well just about all of it -- is 
> exposed via the mtd interface. That tells you the number of blocks, block 
> size, bytes per block etc. Enough to figure out almost all the runtime stuff.

Right, which is why I'm assuming that this build time configuration
stuff is things that can't be read directly from the hardware and needs
to be passed in via some other mechanism.  If it's stuff that can be
read from the MTD subsystem then clearly it should be read from the MTD
subsystem.

> I think I can dump all the config stuff and just set it to the most useful 
> defaults. Many of the settings are really only there for debug etc.

That sounds like a good plan.
--
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/