public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: Ville Herva <vherva@vianova.fi>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH] [MTD] block2mtd.c: Make kernel boot command line arguments work
Date: Thu, 6 Jul 2006 16:13:57 +0200	[thread overview]
Message-ID: <20060706141356.GA30171@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <20060706082443.GL15078@vianova.fi>

On Thu, 6 July 2006 11:24:44 +0300, Ville Herva wrote:
> 
> Trying to pass kernel command line arguments to block2mtd at boot-time does
> not work currently. block2mtd_setup() is called so early that kmalloc()
> fails nevermind being able to do open_bdev_excl() (which requires rootfs to
> be mounted. This patch only saves the option string at the early boot stage,
> and parses them later when block2mtd_init() is called. If open_bdev_excl()
> fails, open_by_devnum(name_to_dev_t()) is tried instead, which makes it
> possible to initialize the driver before rootfs has been mounted. Also gets
> rid of the superfluous parse_name() that only checks if name is longer than
> 80 chars and copies it to a string that is not kfreed.
> 
> With this patch, I can boot statically compiled block2mtd, and mount jffs2
> as rootfs (without modules or initrd), with lilo config like this:
> 
>    root=/dev/mtdblock0
>    append="rootfstype=jffs2 block2mtd.block2mtd=/dev/hdc2,65536"
> 
> (Note that rootfstype=jffs2 is required, since the kernel only tries
> filesystems without "nodev" attribute by default, and jffs is "nodev").

Looks fairly good as a basis.  A couple of details still remain...

> @@ -426,14 +420,20 @@ static inline void kill_final_newline(ch
>  	return 0;				\
>  } while (0)
>  
> -static int block2mtd_setup(const char *val, struct kernel_param *kp)
> +static int block2mtd_init_called = 0;
> +static char block2mtd_paramline[80 + 12]; /* 80 for device, 12 for erase size */
> +
> +
> +static int block2mtd_setup2(void)
>  {
> -	char buf[80+12]; /* 80 for device, 12 for erase size */
> +	char* val = (char*)block2mtd_paramline;

The * usually belongs to the var, not the type.  Also, I believe we
don't need the cast here.
	char *val = block2mtd_paramline;
> +
> +	char buf[80 + 12], *str = buf; /* 80 for device, 12 for erase size */
>  	char *str = buf;

Now we have two variables called "str".

>  	if (token[1]) {
> -		ret = parse_num(&erase_size, token[1]);
> +		int ret = parse_num(&erase_size, token[1]);

Maybe the variable declaration can stay at the top of the function,
just to reduce the amount of churn.

> +static int block2mtd_setup(const char *val, struct kernel_param *kp)
> +{
> +	/* Only save the parameters here. We must parse them later:
> +	   if the param passed from kernel boot command line,
> +	   block2mtd_setup() is called so early that it is not
> +	   possible to resolve the device (even kmalloc() fails).
> +	   Deter that work to block2mtd_setup2(). */
> +
> +	strlcpy(block2mtd_paramline, val, sizeof(block2mtd_paramline));
> +
> +	/* If more parameters are later passed in via
> +	   /sys/module/block2mtd/parameters/block2mtd
> +	   and block2mtd_init() has already been called,
> +	   we can parse the argument now. */
> +
> +	if (block2mtd_init_called)
> +		return block2mtd_setup2();

Took me a couple of minutes to understand what you're doing here.
Makes sense.  But passing the parameter to block2mtd_setup2() through
a global variable instead of stack allows races when two people add
device through the /sys/... file.  We could add spinlocks around this
function and block2mtd_init() to solve that.  Or we could decide it's
not worth the effort.

If you can address the first two comments, I'm happy.

Jörn

-- 
Do not stop an army on its way home.
-- Sun Tzu

  reply	other threads:[~2006-07-06 14:14 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-07-06  8:24 [PATCH] [MTD] block2mtd.c: Make kernel boot command line arguments work Ville Herva
2006-07-06 14:13 ` Jörn Engel [this message]
2006-07-06 15:33   ` Ville Herva

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=20060706141356.GA30171@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vherva@vianova.fi \
    /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