On Thu, 28 Sep 2017 10:02:23 +0200, Jean Delvare wrote: > On Wed, 27 Sep 2017 15:31:04 +0200, Ingo Molnar wrote: > > At minimum I'd suggest aligning the definitions vertically, to make sure > > any missing \n stands out more, visually: > > > > STANDARD_PARAM_DEF(byte, unsigned char, "%hhu\n", > > kstrtou8); > > STANDARD_PARAM_DEF(short, short, "%hi\n", > > kstrtos16); > > STANDARD_PARAM_DEF(ushort, unsigned short, "%hu\n", > > kstrtou16); > > STANDARD_PARAM_DEF(int, int, "%i\n", > > kstrtoint); > > STANDARD_PARAM_DEF(uint, unsigned int, "%u\n", > > kstrtouint); > > STANDARD_PARAM_DEF(long, long, "%li\n", > > kstrtol); > > STANDARD_PARAM_DEF(ulong, unsigned long, "%lu\n", > > kstrtoul); > > STANDARD_PARAM_DEF(ullong, unsigned long long, "%llu\n", > > kstrtoull); > > Sure it is possible to add a new parameter type. But why would the > person adding it forget the \n? I can't imagine that someone adding a > new type would type the new line of code character by character. Such an > operation is calling for copy, paste and edit, at which point there is > no reason why the \n would be actively deleted. Or this is sabotage, > really ;-) > > Aligning parameters vertically as you suggest above is probably a good > idea for overall readability anyway, so I can change my patch to do > that, as I am modifying these lines anyway. It is pretty much > independent from the fix per se, but if it makes you happy...
Or... I could append the \n inside the STANDARD_PARAM_DEF macro, so the calls are unchanged. Makes my patch smaller, and addresses your concern just as well, I suppose. -- Jean Delvare SUSE L3 Support
