Ok, in finding out a bit more of what the EEPROM driver is trying to do,
it looks like it qualifies for the "binary file in sysfs" exception.
It's just exporting a binary blob of data that exists in hardware
through the kernel to userspace, for userspace to do with it what it
wants to.
I'll work on converting the driver to that interface later tonight,
unless someone beats me to it :)
> Furthermore, I think that checksum data is not something that should be
> in the kernel, but in the application that is using it. An application can
> open() /dev/eepromX (/dev/nvramX maybe?) and read the data and ensure that
> the checksum is OK. Not all applications will have the same checksum
> mechanism, location, etc.
>
> From my experience in seeing I2C eeproms on embedded systems, most
> people end up writing a custom little driver that does just what I
> said above: read/write/llseek. The eeprom driver should export the data
> for each eeprom through /dev/eeprom interfaces This also allows for someone
> to add a driver for larger EEPROMs (I have 512byte eeproms on some embedded
> boards) w/o having to add even more entries to sysfs for the remaining data.
I think the "one binary file" will work for all of your varied systems,
right?
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/