Re: at24 driver - a possible problem

[Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]


> > 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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]