Re: at24 driver - a possible problem

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

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