Messages in this thread | | | Date | Wed, 16 Mar 2011 13:49:20 +0300 | From | Alexey Mikhailov <> | Subject | Re: lseek() on debugfs entries in 2.6.37 |
| |
At Tue, 15 Mar 2011 15:01:41 +0100, Arnd Bergmann wrote: Hello!
> > On Tuesday 15 March 2011, Alexey Mikhailov wrote: > > I use simple debugfs entries for user-space <-> kernel-space > > interaction. Basically I read unsigned integers from debugfs > > files like this: > > > > ... > > char buf[64]; > > lseek(timesync_fd, 0, SEEK_SET); > > read(timesync_fd, buf, sizeof(buf)); > > ... > > > > It works perfectly with 2.6.32 kernel. But with 2.6.37 kernel, > > lseek() fails with errno=29(Illegal seek). So second read() > > call just fails or returns garbage. Can someone please shed > > some light on it? > > This is probably a result of the changes I made as part of the > BKL removal. Which file specifically are you talking about? > > In older kernels, having no .llseek function meant that you > implicitly get default_llseek. New kernels now require > that the driver explicitly chooses one llseek variant.
Thank you for reply. Obvious patches like this one fixed it
static struct file_operations fops_timesync = { .owner = THIS_MODULE, .open = fop_open_timesync, .read = fop_read_timesync, + .llseek = default_llseek, };
I assume there is the reason you need to specify this explicitly as it will break much out-of-kernel code.
-- Alexey
| |