linux-kernel - Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board Information EEPROM 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 16 Oct 2014 11:59:10 +0200
From:	Wolfram Sang <wsa@...-dreams.de>
To:	Andreas Werner <andreas.werner@....de>
Cc:	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	linux-i2c@...r.kernel.org, johannes.thumshirn@....de
Subject: Re: [PATCH 1/2] drivers/misc/eeprom/men_eeprod: Introduce MEN Board
 Information EEPROM driver

> I do not want to parse the things in userspace because this EEPROM data
> are related to the hardware and i want to give our customer the easiest way
> to access the data without installing any tool.

I understand that point of view. From an upstream point of view, things
may look different, though.

> The current state to read the eeprom data is, that customer needs to install a big
> environment where the tool is integrated to have access to those kind of simple
> data or they have to write their own code.

i2cget from i2c-tools? You could do a simple shell script to parse the
data. Or do a board specific hook which reads the data and prints it to
the logfiles...

> > Consider how bloated the sysfs-ABI might get if every vendor who uses an
> > eeprom wants to expose the data this way?
> > 
> 
> Yes and no. The possible sysfs entries gets bloated if every vendor will do it
> like this way, but normally there is just one Board EEPROM on the board, therefore
> only one driver gets loaded.

I am not talking about runtime here, I don't care about that. I am
talking about the ABI we create and we have to maintain basically
forever. And with vendor specific configuartion data I have doubts with
that being stable.

> I mean its the same for every i2c device like a temperature sensor, I can also
> read it from userspace without any special hwmon driver.

These is a HUGE difference. If I read tempX_input, I don't need to care
if the sensor is I2C or SPI or whatever. The kernel abstracts that away.
The files you create are for your I2C EEPROM only. Data gets
"reformatted" and access gets hidden, but nothing is abstracted away.
It would be different if we had a generic convention for "serial_id" or
stuff like that. But as configuration data is highly specific I don't
see this coming.

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