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]

Message-ID: <BANLkTimMndGzjZJ0xUNgStY7kwM0aW7Ojg@mail.gmail.com>
Date:	Fri, 20 May 2011 15:40:06 -0700
From:	Eric Biederman <ebiederm@...stanetworks.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Chris Metcalf <cmetcalf@...era.com>, linux-kernel@...r.kernel.org,
	Chris Wright <chrisw@...s-sol.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	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 Fri, May 20, 2011 at 11:46 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Friday 20 May 2011 20:05:05 Chris Metcalf wrote:
>> This works well, except for the fact that we take advantage of the fact
>> that the hypervisor driver internally buffers up writes to the current
>> EEPROM sector, and flushes it to hardware only when explicitly told to do
>> so, or when we start writing to another sector.  This avoids excessive wear
>> on the EEPROM and also handles detection of whether we need to do a sector
>> erase before the re-write.  However, it also means that we need to be able
>> to issue the final explicit flush, or else the last write just sits in the
>> hypervisor buffer indefinitely.  To make that happen I think I need to
>> extend the bin_attribute structure, and the bin.c release() function, slightly:
>
> Yes, that would work. Another option would be to add a flush() callback
> to the bin_attribute. Since filp_close calls both fops->flush and
> fops->release, that would also make it possible to flush the buffer
> without closing it, if necessary.

Ouch!

Please do not make sysfs the direct access method to your device.

I may be wrong but I don't think any other driver relies exclusively on sysfs.
Certainly with the introduction of a flush you are introducing an completely
different usage paradigm from current users and will need an entirely different
set of tools.

You are vastly exceeding the one value per file rule of sysfs.

Please look at the i2c core and if at all possible build a proper interface to
your eeprom, that existing programs have a chance of utilizing rather than
extending sysfs in ways that means cli tools can not work with it.

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/