> > Still, the latter one beats me right now. The sysfs-bin-write gets a kobject > > and the O_SYNC is placed in the flags of a filp during open. Is there a some > > connection between those? I'm not even sure if O_SYNC should be handled at > > the > > sysfs-layer instead of inside the driver? > > I'm not sure how sysfs could handle it. What backs up the sysfs file is > driver-specific, so only the driver knows how to ensure that the data > has been written. In the at24 driver case, the only way AFAICS is to > try to read one byte back from the EEPROM and only return when the read > is successful.
ACK. Sorry, I was not specific here. I also imagined that a solution must look
like:
if (flag_however_I_get_it == O_SYNC)
at24_eeprom_read(...)
most probably in at24_write().
What I meant with "handled at sysfs-layer" was that it felt wrong to look for
some complicated way from the kobject to the O_SYNC flag. It appeared to me
that it might be more suitable to let the sysfs-layer recognize the flag during
open and then, maybe, set another flag in a struct which is easier to reach for
a bin-file. Then again, I wondered how many sysfs-bin files would really need
that and that the "eeprom"-bin file might be a gray area (because of really
acessing a media).
> is entirely possible that sysfs simply has no support for O flags. This
> would have to be discussed at a higher level.
Most probably.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
