On Sun, 8 Nov 2009 21:23:31 +0100, Wolfram Sang wrote: > > > Correct me if I'm wrong but I would expect from a synchronous write() > > > call to NOT finish before the data has been "phisically written". > > > And in this case of course the read operation wouldn't need a waiting loop. > > > What do you think? > > > > Makes sense to me. Another bug to fix. :) > > I think the waiting loop in the read-path won't hurt and will be convenient for > a number of users. I also think it would be nice if O_SYNC would be supported, > so the write will only return after the EEPROM finished the write cycle. > > 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. But looking at the sysfs API, I can't see a way to retrieve O_SYNC from the driver, nor room for a callback that would let sysfs handle it. It is entirely possible that sysfs simply has no support for O flags. This would have to be discussed at a higher level. -- Jean Delvare -- 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
