On Thu, Oct 16, 2014 at 01:44:02PM +0200, Andreas Werner wrote: > On Thu, Oct 16, 2014 at 11:59:10AM +0200, Wolfram Sang wrote: > > * PGP Signed by an unknown key > > > > > > > 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. > > > > I also understand your point of view :-). > 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. > > > > 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... > > > > Yes of course there are a lot of possibilities. This was just an example > what we currently use and what was developed years ago. > > 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. > > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > Regards > Andy > Greg what do you think about that driver as a Maintainer of the sysfs? To we have other ways to get those kind of drivers in the mainline kernel? Regards Andy > > > > * Unknown Key > > * 0x14A029B6 -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
