SYSFS: need a noncaching read

Michael Ellerman michael at ellerman.id.au
Wed Sep 12 13:18:11 EST 2007


On Wed, 2007-09-12 at 12:05 +1000, David Gibson wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > Hello,
> > 
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace. I opened the sysFS File for one register and did
> > some reads from this File, but I alwas becoming the same value from the
> > register, whats not OK, because they are changing. So I found out that
> > the sysFS caches the reads ... :-(
> > 
> > Is there a way to retrigger the reads (in that way, that the sysFS
> > rereads the values from the driver), without closing and opening the
> > sysFS Files? Or must I better use the ioctl () Driver-interface for
> > exporting these registers?
> > 
> > I am asking this, because I must read every 10 ms 2 registers, so
> > doing a open/read/close for reading one registers is a little bit too
> > much overhead.
> > 
> > I made a sysFS seek function, which retriggers the read, and that works
> > fine, but I have again 2 syscalls, whats also is not optimal.
> > 
> > Or can we make a open () with a (new?)Flag, that informs the sysFS to
> > always reread the values from the underlying driver?
> > 
> > Or a new flag in the "struct attribute_group" in include/linux/sysfs.h,
> > which let the sysfs rereading the values?
> 
> This sounds more like sysfs is really not the right interface for
> polling your registers.  You would probably be better off having your
> driver export a character device from which the register values could
> be read.

I thought relay(fs) was the trendy way to do this these days?

Documentation/filesystems/relay.txt

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070912/14b996ef/attachment.pgp>


More information about the Linuxppc-dev mailing list