> > 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/ |
Attachment:
signature.asc
Description: Digital signature
