Linux-RISC-V Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: mick@ics.forth.gr (Nick Kossifidis)
To: linux-riscv@lists.infradead.org
Subject: [PATCH] RISC-V: Implement built-in command line feature
Date: Tue, 02 Oct 2018 18:21:26 +0300	[thread overview]
Message-ID: <a425c3cc9507782d305f802232704077@mailhost.ics.forth.gr> (raw)
In-Reply-To: <20181002143455.GA1476@infradead.org>

???? 2018-10-02 17:34, Christoph Hellwig ??????:
>> +#ifdef CONFIG_CMDLINE_BOOL
>> +#ifdef CONFIG_CMDLINE_FORCE
>> +	static const char fixed_cmdline[] __initconst = CONFIG_CMDLINE;
>> +#else
>> +	static char builtin_cmdline[] __initdata = CONFIG_CMDLINE;
>> +#endif
>> +#endif
> 
> Why do you need two variables here?  x86, where this same logic is used
> seems to get away with just a builtin_cmdline command line one.
> 

x86 actually uses an extra buffer named command_line, copies 
boot_command_line
there and returns a pointer to command_line (instead of just returning a 
pointer
to boot_command_line). What I do here is in case we have a forced 
command line,
I prefer having it as const (since the buffer won't get modified) 
instead of
having it as rw. I believe it's cleaner and the name is more 
representative.

> Also please don't indent code inside cpp conditionals.
> 

ACK (although there is nothing against it on the kernel coding 
guidelines)

>> +	/* When we return, cmdline_p should point to a temporary
> 
> This is not the normal kernel comment style.  Please keep the
> /* on a line of its own.
> 

It is for drivers/net where I've mostly worked (drivers/net/wireless) 
but you are
right, I'll fix it and re-send.

>> +#ifdef CONFIG_CMDLINE_BOOL
>> +#ifdef CONFIG_CMDLINE_FORCE
>> +	/* Built-in args override boot loader args and
>> +	 * boot loader args are being ignored.
>> +	 */
>> +	strlcpy(boot_command_line, fixed_cmdline, COMMAND_LINE_SIZE);
>> +#else
>> +	/* Boot loader args override built-in args so we
>> +	 * need to put built-in args before boot loader args.
>> +	 */
>> +	if (builtin_cmdline[0]) {
>> +		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
>> +		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
>> +		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> +	}
>> +#endif
>> +#endif
> 
> Even if this seems mostly copied - it probably should be #if/#elif
> instead of this convoluted magic:
> 
> #if defined(CONFIG_CMDLINE_FORCE)
> 	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> #elif defined(CONFIG_CMDLINE_BOOL)
> 	if (builtin_cmdline[0]) {
> 		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> 		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> 		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> 	}
> #endif

There is a reason behind this "magic" IMHO, in your approach the reader 
doesn't realize
that CONFIG_CMDLINE_FORCE depends on CONFIG_CMDLINE_BOOL.

WARNING: multiple messages have this Message-ID (diff)
From: Nick Kossifidis <mick@ics.forth.gr>
To: Christoph Hellwig <hch@infradead.org>
Cc: Nick Kossifidis <mick@ics.forth.gr>,
	linux-riscv@lists.infradead.org, palmer@sifive.com,
	aou@eecs.berkeley.edu
Subject: Re: [PATCH] RISC-V: Implement built-in command line feature
Date: Tue, 02 Oct 2018 18:21:26 +0300	[thread overview]
Message-ID: <a425c3cc9507782d305f802232704077@mailhost.ics.forth.gr> (raw)
Message-ID: <20181002152126.dMVDPCbPNg92Q2rJblDOgo_mtjs8dkOzXr8yn6FghdA@z> (raw)
In-Reply-To: <20181002143455.GA1476@infradead.org>

Στις 2018-10-02 17:34, Christoph Hellwig έγραψε:
>> +#ifdef CONFIG_CMDLINE_BOOL
>> +#ifdef CONFIG_CMDLINE_FORCE
>> +	static const char fixed_cmdline[] __initconst = CONFIG_CMDLINE;
>> +#else
>> +	static char builtin_cmdline[] __initdata = CONFIG_CMDLINE;
>> +#endif
>> +#endif
> 
> Why do you need two variables here?  x86, where this same logic is used
> seems to get away with just a builtin_cmdline command line one.
> 

x86 actually uses an extra buffer named command_line, copies 
boot_command_line
there and returns a pointer to command_line (instead of just returning a 
pointer
to boot_command_line). What I do here is in case we have a forced 
command line,
I prefer having it as const (since the buffer won't get modified) 
instead of
having it as rw. I believe it's cleaner and the name is more 
representative.

> Also please don't indent code inside cpp conditionals.
> 

ACK (although there is nothing against it on the kernel coding 
guidelines)

>> +	/* When we return, cmdline_p should point to a temporary
> 
> This is not the normal kernel comment style.  Please keep the
> /* on a line of its own.
> 

It is for drivers/net where I've mostly worked (drivers/net/wireless) 
but you are
right, I'll fix it and re-send.

>> +#ifdef CONFIG_CMDLINE_BOOL
>> +#ifdef CONFIG_CMDLINE_FORCE
>> +	/* Built-in args override boot loader args and
>> +	 * boot loader args are being ignored.
>> +	 */
>> +	strlcpy(boot_command_line, fixed_cmdline, COMMAND_LINE_SIZE);
>> +#else
>> +	/* Boot loader args override built-in args so we
>> +	 * need to put built-in args before boot loader args.
>> +	 */
>> +	if (builtin_cmdline[0]) {
>> +		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
>> +		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
>> +		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
>> +	}
>> +#endif
>> +#endif
> 
> Even if this seems mostly copied - it probably should be #if/#elif
> instead of this convoluted magic:
> 
> #if defined(CONFIG_CMDLINE_FORCE)
> 	strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> #elif defined(CONFIG_CMDLINE_BOOL)
> 	if (builtin_cmdline[0]) {
> 		strlcat(builtin_cmdline, " ", COMMAND_LINE_SIZE);
> 		strlcat(builtin_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> 		strlcpy(boot_command_line, builtin_cmdline, COMMAND_LINE_SIZE);
> 	}
> #endif

There is a reason behind this "magic" IMHO, in your approach the reader 
doesn't realize
that CONFIG_CMDLINE_FORCE depends on CONFIG_CMDLINE_BOOL.


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2018-10-02 15:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-02 14:04 [PATCH] RISC-V: Implement built-in command line feature Nick Kossifidis
2018-10-02 14:04 ` Nick Kossifidis
2018-10-02 14:34 ` Christoph Hellwig
2018-10-02 14:34   ` Christoph Hellwig
2018-10-02 15:21   ` Nick Kossifidis [this message]
2018-10-02 15:21     ` Nick Kossifidis
2018-10-02 14:56 ` Palmer Dabbelt
2018-10-02 14:56   ` Palmer Dabbelt
2018-10-02 16:43   ` Nick Kossifidis
2018-10-02 16:43     ` Nick Kossifidis
2018-10-02 16:56     ` Palmer Dabbelt
2018-10-02 16:56       ` Palmer Dabbelt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a425c3cc9507782d305f802232704077@mailhost.ics.forth.gr \
    --to=mick@ics.forth.gr \
    --cc=linux-riscv@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox