This seems to be the relevant patch: https://lkml.org/lkml/2010/5/5/104 Amerigo Wang <amw...@redhat.com> 2010-05-05 02:26:45 00b7c3395aec3df43de5bd02a3c5a099ca51169f +static const char proc_wspace_sep[] = { ' ', '\t', '\n' };
So since 2010 we have the current behavior. Best regards Heinrich Schuchardt On 24.08.2015 22:44, Andrew Morton wrote: > On Mon, 24 Aug 2015 23:33:58 +0800 Sean Fu <fxinr...@gmail.com> wrote: > >> On Mon, Aug 24, 2015 at 8:27 PM, Eric W. Biederman >> <ebied...@xmission.com> wrote: >>> >>> >>> On August 24, 2015 1:56:13 AM PDT, Sean Fu <fxinr...@gmail.com> wrote: >>>> when the input argument "count" including the terminating byte "\0", >>>> The write system call return EINVAL on proc file. >>>> But it return success on regular file. >>> >>> Nonsense. It will write the '\0' to a regular file because it is just data. >>> >>> Integers in proc are more than data. >>> >>> So I see no justification for this change. >> In fact, "write(fd, "1\0", 2)" on Integers proc file return success on >> 2.6 kernel. I already tested it on 2.6.6.60 kernel. >> >> So, The latest behavior of "write(fd, "1\0", 2)" is different from old >> kernel(2.6). >> This maybe impact the compatibility of some user space program. > > 2.6 was a long time ago. If this behaviour change has happened in the > last 1-2 kernel releases then there would be a case to consider making > changes. But if the kernel has been this way for two years then it's > too late to bother switching back to the old (and strange) behaviour. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/