linux-kernel - Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver

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:	Sat, 21 May 2011 08:50:43 -0700
From:	Eric Biederman <ebiederm@...stanetworks.com>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	Arnd Bergmann <arnd@...db.de>, Greg KH <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, Chris Wright <chrisw@...s-sol.org>,
	Benjamin Thery <benjamin.thery@...l.net>,
	Phil Carmody <ext-phil.2.carmody@...ia.com>
Subject: Re: [PATCH] arch/tile: add arch/tile/drivers/ directory with SROM driver

On Sat, May 21, 2011 at 6:52 AM, Chris Metcalf <cmetcalf@...era.com> wrote:
> Interesting!  I did in fact assume that most tools that read or write
> eeproms would tend to be "batch" tools, i.e. they would read or write
> whatever it was they wanted, then exit; the tool we have that modifies this
> EEPROM is written like that, for example.  It sounds like you're saying
> there are (or may be) tools that open the file descriptor and do writes to
> it, then don't exit or close the file descriptor, but expect the last write
> to have hit the device immediately.  It's fair to say that since my
> suggested API does defer the last sector's worth of writes until the app
> exits, it potentially violates that assumption, so it's a bad idea.

Plus the other gigantic difference that I have seen very few eeproms
that can hold a sectors worth of data.

My reading of this conversation is that you are confusing a configuration
eeprom with a nor flash boot device.  That is a bit like confusing a yellow
sticky not with the Encyclopedia Britannica.   They aren't at all the
same thing.

> On 5/21/2011 3:46 AM, Eric Biederman wrote:
>> What is wrong with an mtd driver?
>
> More backstory: we actually have an MTD driver for this device (in our
> local tree as drivers/mtd/devices/tile_srom.c) but we haven't yet tried to
> push it back to the community.  But it doesn't work for the most important
> purpose of this device, namely to serve as one of the possible boot streams
> at power-on.  For this, we have to control exactly what data is on what
> sector, which means a character (or sysfs) device.

How can an MTD driver not work to control exactly what data is on what
sector????  That is what MTD drivers do.

It sounds like you have a bug in either your userspace tools or your
implementation of your mtd driver.  That is definitely not a reason to
dump your device into a char device (mtdchar already exists).

> Sounds like the consensus is that a character driver is in fact the best
> option here.

I think the consensus is that your design is buggy.

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