Messages in this thread | | | From | (Eric W. Biederman) | Subject | Re: [PATCH] Support single byte reads from integers published in procfs by kernel/sysctl.c | Date | Mon, 23 Jan 2012 08:35:15 -0800 |
| |
Earl Chew <echew@ixiacom.com> writes:
> On 23/01/2012 6:47 AM, Eric W. Biederman wrote: >> The difference between strings and integers is that with strings >> single byte reads/writes actually make sense. >> >> Single decimal digits reads don't make much sense at all for integers. >> >> Is there any compelling reason to support this complete idiocy from user >> space programs? > > Eric, > > [ I also note that the patch allows multiple short reads (not necessarily > just a single byte at a time) from these entries in procfs. ] > > I think there is a reasonable userspace expectation that entities > that present themselves as text files to produce results that are > consistent with the userspace model of a text file. > > For a more concrete example, consider the following BusyBox ash(1) code: > > read X < /proc/sys/kernel/threads-max > Y=$(cat /proc/sys/kernel/threads-max) > > read A < /proc/sys/kernel/core_pattern > B=$(cat /proc/sys/kernel/core_pattern)
> The fact that these yield different results is surprising given that > the user sees these as text files. > > I think it is worthwhile asking the opposite question, > > " Is there any compelling reason for the kernel to require userspace > programs to access /proc/sys/kernel/threads-max any differently > from, say, /etc/fstab ? " > > If the answer is in the affirmative, then it requires some layer in > the userspace program (presumably the IO layer) to make some > special accommodation for some entries in /proc. > > As can be seen in the case of BusyBox, this approach might be difficult > to swallow in something as generic as ash(1), so it is left to the user to > puzzle out why read fails, but cat works -- but only sometimes.
read X < file seems like a reasonable case to support. Bash doesn't have that problem so presumably BusyBox is simply inefficient.
If you are interested in fixing this properly with a tiny buffer reachable from struct file I think this can be worth fixing. I think this is doable by using seq_file in proc_sys_read.
Rereading different bytes of the integer multiple times when the integer may be changing does not seem like a reasonable implementation.
Eric
| |