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?
suggestions are welcome
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
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.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
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
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> I have developed a device driver and use the sysFS to export some
> registers to userspace.
Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
not to play around with registers from 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 ... :-(
Yes, it does. What you can do is close()ing the file handle between
accesses, which makes it work but is slow.
> 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?
What kind of problem do you want to solve? Userspace is for
applications, and applications usually don't have to know about hardware
details like registers. So if you have to do something every 10 ms from
userspace, your design is probably wrong.
If you absolutely need to do such things from userspace, have a look at
uio. But in most cases the answer is: make a proper abstraction for the
problem you wanna solve and write a proper driver.
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace.
>
> Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> not to play around with registers from 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 ... :-(
>
> Yes, it does. What you can do is close()ing the file handle between
> accesses, which makes it work but is slow.
Do an lseek back to 0 and then re-read, you will get called in your
driver again.
Not that this is a good thing to do for this kind of thing, as others
have already said.
thanks,
greg k-h
Hello Greg
Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from 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 ... :-(
> >
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
No thats not true. I thought this too, but if I make a:
seek (fd, 0L, SEEK_SET);
in Userspace, there is no retrigger in the sysFS, my driver is *not*
called again. So I made a own sysfs_seek function, which does retrigger
the driver ...
Is this really wanted in the sysFS, that there is no way to retrigger a
read?
thanks
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
On Wed, Sep 12, 2007 at 01:13:32PM +0200, Heiko Schocher wrote:
> Hello Greg
>
> Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have developed a device driver and use the sysFS to export some
> > > > registers to userspace.
> > >
> > > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > > not to play around with registers from 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 ... :-(
> > >
> > > Yes, it does. What you can do is close()ing the file handle between
> > > accesses, which makes it work but is slow.
> >
> > Do an lseek back to 0 and then re-read, you will get called in your
> > driver again.
>
> No thats not true. I thought this too, but if I make a:
>
> seek (fd, 0L, SEEK_SET);
>
> in Userspace, there is no retrigger in the sysFS, my driver is *not*
> called again. So I made a own sysfs_seek function, which does retrigger
> the driver ...
Hm, are you sure? Otherwise the poll() stuff would not work at all.
> Is this really wanted in the sysFS, that there is no way to retrigger a
> read?
Yes, use the sysfs poll/select stuff to do that.
And "sysfs" has no upper-case letters :)
thanks,
greg k-h
Hello Greg,
Am Mittwoch, den 12.09.2007, 04:39 -0700 schrieb Greg KH:
> > > Do an lseek back to 0 and then re-read, you will get called in your
> > > driver again.
> >
> > No thats not true. I thought this too, but if I make a:
> >
> > seek (fd, 0L, SEEK_SET);
> >
> > in Userspace, there is no retrigger in the sysFS, my driver is *not*
> > called again. So I made a own sysfs_seek function, which does retrigger
> > the driver ...
>
> Hm, are you sure? Otherwise the poll() stuff would not work at all.
Yes.
Sysfs uses generic_file_llseek (). And in sysfs_read_file ()
buffer->needs_read_fill must be 1, to reread from the driver.
generic_file_llseek () doesnt change this variable.
Best regards
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
On Wednesday 12 September 2007 20:01, Greg KH wrote:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> >
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from 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 ... :-(
> >
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
Can you do a pread with offset 0 to avoid the two syscalls? (which some
people seem to be concerned about)
On Wednesday September 12, [email protected] wrote:
> On Wednesday 12 September 2007 20:01, Greg KH wrote:
> > On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > > I have developed a device driver and use the sysFS to export some
> > > > registers to userspace.
> > >
> > > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > > not to play around with registers from 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 ... :-(
> > >
> > > Yes, it does. What you can do is close()ing the file handle between
> > > accesses, which makes it work but is slow.
> >
> > Do an lseek back to 0 and then re-read, you will get called in your
> > driver again.
>
> Can you do a pread with offset 0 to avoid the two syscalls? (which some
> people seem to be concerned about)
No.
Looking in fs/sysfs/file.c, we notice the field "needs_read_fill" in
struct sysfs_buffer.
sysfs_read_file will only call fill_read_buffer (which calls the
->show routine) if this is 1;
It is cleared by fill_read_buffer and set to 1:
- at open
- by fill_write_buffer (i.e. if you write to the file descriptor)
- by sysfs_poll when an event was detected.
So currently you cannot simply open a sysfs file an read multiple
times.
One option would be to call fill_read_buffer if *ppos == 0.
I cannot see that being a problem in practice, but maybe there is a
reason why it wasn't done that way.
Another option might be to call fill_read_buffer also if
buffer->event != atomic_read(&attr_sd->s_event)
and require drivers to call sysfs_notify when they make a change that
should be noticed. But I doubt that is really important.
NeilBrown
Greg KH wrote:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
>> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
>>> I have developed a device driver and use the sysFS to export some
>>> registers to userspace.
>> Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
>> not to play around with registers from 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 ... :-(
>> Yes, it does. What you can do is close()ing the file handle between
>> accesses, which makes it work but is slow.
>
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.
There should be an intervening sysfs_notify() call from kernel side to
make sysfs re-populate its cache on read again. sysfs bin files buffer
the result but don't cache the result but this again doesn't really fit
the usage case.
Thanks.
--
tejun