On Thu, Feb 19, 2015 at 5:53 PM, folkert <[email protected]> wrote: >> >> >> Try using lseek before reading the data after the poll. >> >> >> >> >> >> EX. >> >> >> if (fdset[0].revents & POLLPRI) { >> >> >> lseek(fdset[0].fd, 0, SEEK_SET); >> >> >> len = read(fdset[0].fd, buf, MAX_BUF); >> >> >> . >> >> >> . >> >> >> } >> >> >> >> >> >> See if this helps. >> >> > >> >> > Yes, that fixed it! >> >> >> >> Still, shouldn't we consider this as a regression, especially if not >> >> using lseek worked for kernel 3.12 and before? >> > >> > Perhaps this is a side effect of the sysfs to kernfs change over to >> > happened in >> > 3.14. >> > >> > Looking at 'kernfs_fop_poll' my guess is that 'kernfs_get_active' is >> > returning NULL >> > immediately returning from the poll command and causing described behavior. >> > >> > http://lxr.free-electrons.com/source/fs/kernfs/file.c#L763 >> >> I think this looks plausible. >> Folkert what do you say about this? > > That looks indeed to be the current situation. It worked different > before though. > > I also think that this interface is cumbersome. I did not measure it(!) > but I think adding this open/seek + read construction may add all kinds > of overhead. Especially since my use-case requires the lowest latency > possible. Not to forget that conversion of the measured value to ascii > and back.
Folkert, since you have code that can reproduce the issue, could you see whether you could come with a patch that restores the original behavior? Maybe by introducing a in-kernel lseek() as soon as the file is opened? -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
