Hi, On Thu, Dec 30, 2021 at 07:19:06PM +0100, Vincent Danjean wrote: > On 30/12/2021 14:52, Bastian Blank wrote: > > On Mon, Dec 27, 2021 at 11:31:21PM +0100, Vincent Danjean wrote: > > > On a plain (with more than two bytes) file, the second poll succeed. > > > On /proc/bus/input/devices, the second poll hangs. > > > Note: this is an old behavior. I initially observe it on an embeded > > > system with > > > a 4.1 kernel. > > > > /proc is no real filesystem. It simply does not support poll, because > > the output is generated while you are reading it, so it does not know > > when anything changes. See also > > https://unix.stackexchange.com/questions/74713/how-frequently-is-the-proc-file-system-updated-on-linux?rq=1 > > > > If you want to know about hardware changes, use udev or listen to kernel > > netlink messages. > > I understand that /proc is different. But I'm not monitoring it. > My goal was only to read it totally from a busybox shell with a > "while read" loop to find the eventX associated with the > touchscreen of the e-reader. > And the first read from busybox shell never complete (instead of > returning the first line of the file) due to the fact that > busybox use poll, then read a byte, then use poll again. > > > Do you think I should reassign this bug to busybox? > > Or do you think I'm wrong trying to read the /proc file > from a shell script without to copy it elsewhere before? > > Stalling: > busybox sh -c 'while read l ; do echo $l ; done < /proc/bus/input/devices' > Working (but bash is not present on the initial target system): > bash -c 'while read l ; do echo $l ; done < /proc/bus/input/devices' > > As workaround, I'm currently using a copy of the file > ("busybox cp" works). It should probably also be possible > to get the same kind of info from /sys files but this seems > less easy. > > I just saw that other files seems to work: > Ok: > busybox sh -c 'read l < /proc/bus/input/handlers ; echo $l' > Stale: > busybox sh -c 'read l < /proc/bus/input/devices ; echo $l' > > Regards, > Vincent
Do we still consider this a valid src:linux bug or should it be closed, reassigned? Regards, Salvatore
