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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20141020081822.GA1413@katana>
Date:	Mon, 20 Oct 2014 10:18:22 +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

> Most customers wants just to have a running system without installing anything.
> And for me an EEPROM is so simple and should not need a complicated way
> to access it.

As I pointed out, there are ways to do it other than a seperate driver.

> Yes of course there are a lot of possibilities. This was just an example
> what we currently use and what was developed years ago.

And please notice that this solution you chose is not acceptible for
upstream. We can't have n copies of the at24 driver with just some minor
differences. This is a maintenance nightmare.

Yes, I know it was easiest to start with and it works, but that does not
help here.

> With a driver like this you can also define read only attributes to prevent customer
> to write or modify the data in the production section. With i2ctools you can just
> write any data to it you want.

i2cget won't modify any data. i2cset does, if anyone wants to do that.
BTW it does that also after you removed your driver, so basically no big
difference here.

> > 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.
> > 
> 
> Ok, but i do not think that we can make a "general" ABI definition for those kind
> of devices because every vendor will have its own data in the EEPROM which he want
> to have.

Exactly, that was what I was saying.

What we probably should have in at24 is regions which should not be
exposed to userspace, because they contain config data. That would be
nice.

I'm not sure if we can add table based decoding to at24, that needs some
experiments. But it will really need such experiments and some more
effort.

> > 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.
> > 
> 
> For a standard sysfs interface it is a huge difference yes. At the point
> of few from the EEPROM device it is a device like a temp sensor which
> could be different from vendor to vendor.

Here it gets frustrating. It seems you have no idea what an OS is for,
not even after I tried to describe it :(

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