Re: [PATCH] Support single byte reads from integers published inprocfs by kernel/sysctl.c

[Earl Chew]

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.

Earl

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/