[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140131200029.13265.72190@capellas-linux>
Date: Fri, 31 Jan 2014 12:00:29 -0800
From: Sebastian Capella <sebastian.capella@...aro.org>
To: Pavel Machek <pavel@....cz>, "David Rientjes" <rientjes@...gle.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linux-pm@...r.kernel.org, linaro-kernel@...ts.linaro.org,
patches@...aro.org, "Andrew Morton" <akpm@...ux-foundation.org>,
"Michel Lespinasse" <walken@...gle.com>,
"Shaohua Li" <shli@...nel.org>,
"Jerome Marchand" <jmarchan@...hat.com>,
"Mikulas Patocka" <mpatocka@...hat.com>,
"Joonsoo Kim" <iamjoonsoo.kim@....com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>
Subject: Re: [PATCH v4 1/2] mm: add kstrimdup function
Quoting Pavel Machek (2014-01-31 04:24:21)
> Well, your /sys/power/resume patch would be nice cleanup, but it
> changs behaviour, too... which is unnice. Stripping trailing "\n" is
> probably neccessary, because we did it before. (It probably was a
> mistake). But kernel is not right place to second-guess what the user
> meant. Just return -EINVAL. This is kernel ABI, after all, not user
> facing shell.
Thanks guys! I hadn't thought of these cases.
It sounds like we're really back to stripping one trailing \n to match
the sysfs behavior to which people have become accustomed, and leave
the rest of the string untouched in case the whitespace is intentional.
Should a user intentionally have input ending in a newline, then they
should add an additional newline, expecting it to be stripped, but
otherwise, their string is taken as entered.
Does this sound right?
Meanwhile, I'll try a test to see how name_to_dev_t handles files with
spaces in them.
Thanks,
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists