* Jean Delvare <jdelv...@suse.de> wrote:
> 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.
Yeah, that would be even better:
Acked-by: Ingo Molnar <mi...@kernel.org>
Note that the vertical alignment makes things easier to read regardless of the
\n.
Thanks,
Ingo
