public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Ralph Sennhauser <ralph.sennhauser@gmail.com>
To: Richard Weinberger <richard@nod.at>
Cc: Daniel Golle <daniel@makrotopia.org>,
	linux-mtd@lists.infradead.org, Zoltan HERPAI <wigyori@uid0.hu>,
	Hauke Mehrtens <hauke@hauke-m.de>,
	lede-dev@lists.infradead.org, openwrt-devel@lists.openwrt.org,
	Boris Brezillon <boris.brezillon@free-electrons.com>,
	Brian Norris <computersforpeace@gmail.com>,
	Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
Subject: Re: [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter
Date: Sun, 28 Aug 2016 09:10:17 +0200	[thread overview]
Message-ID: <20160828091017.06fc2312@gmail.com> (raw)
In-Reply-To: <208b9297-9790-2b2f-6013-49aadb6970cf@nod.at>

Hi Richard,

On Sat, 27 Aug 2016 22:43:45 +0200
Richard Weinberger <richard@nod.at> wrote:

> Daniel,
> 
> On 27.08.2016 21:43, Daniel Golle wrote:
> > Hi!
> > 
> > In an attempts to fix the flaws of the current set of UBI-related
> > patches we are carrying in OpenWrt, I re-wrote the way mounting the
> > rootfs from UBI in OpenWrt/LEDE works. The main requirement I face
> > which cannot be easily addressed using other means which are already
> > available in the kernel is the fact that UBIFS and squashfs-on-UBI
> > require different parameters to be set on the cmdline, e.g.
> > for UBIFS: ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs
> > for squashfs: ubi.mtd=ubi ubiblock=0,1 root=/dev/ubiblock0_1
> > rootfstype=squashfs
> > 
> > The idea behind this patchset is to provide a single syntax which
> > allows mouting rootfs in both cases. To achieve that, the parsing of
> > the volume name string from UBIFS is moved to UBI, so it can be
> > reused by other in-kernel users. This is then used by
> > init/do_mounts.c to create a ubiblock device if the filesystem on
> > the device is non-UBIFS. To actually set this device to be
> > ROOT_DEV, ubiblock_create is extended to allow passing-back the
> > created ubiblock device.
> > 
> > With those changes, a single set of cmdline parameters is
> > sufficient to mount either UBIFS or any other block filesystem
> > by creating a ubiblock device:
> > ubi.mtd=ubi root=ubi0:rootfs rootfstype=ubifs,squashfs  
> 
> well, this all boils down to the point we have already been.
> I will tell you do set the cmdline correctly, either via bootloader
> or devicetree, or use an initramfs.
> 
> I can understand that OpenWrt/LEDE sometimes has to start from a
> hostile bootloader which doesn't let you changing the cmdline.
> But you can still set (and override) it either using CONFIG_CMDLINE or
> in your device tree.
> For advanced booting you can also use a inittamfs.
> 
> So, what do I miss?
> 
> Thanks,
> //richard

Using CONFIG_CMDLINE or the dtb isn't an option either for dual firmware
devices. You'd have to provide two images, one for each partition so
the rootfs belonging to the kernel gets mounted. Sounds like a recipe
for disaster.

On the other hand an initramfs can carry the logic to figure out which
to mount and is what I use for my self. The busybox based implementation
I use adds a tad over 300Kb to the uImage, perfectly acceptable in my
case.

Cheers
Ralph

  parent reply	other threads:[~2016-08-28  7:10 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-27 19:43 [PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter Daniel Golle
2016-08-27 20:43 ` Richard Weinberger
2016-08-27 21:06   ` Daniel Golle
2016-08-27 21:23     ` Richard Weinberger
2016-08-27 23:13       ` Daniel Golle
2016-08-27 23:33         ` Richard Weinberger
2016-08-28  6:47           ` Boris Brezillon
2016-08-28  7:10   ` Ralph Sennhauser [this message]
2016-08-28  8:12     ` Richard Weinberger
2016-08-28  9:19       ` Ralph Sennhauser
2016-08-28  9:28         ` Richard Weinberger
2016-08-28 11:44           ` Daniel Golle
2016-08-28 11:57             ` Richard Weinberger
2016-08-28 13:47               ` Daniel Golle
2016-08-28 14:17                 ` Boris Brezillon
2016-08-28 12:10             ` Ralph Sennhauser
2016-08-28 13:24             ` Boris Brezillon
2016-08-28 14:12 ` Ezequiel Garcia
2016-08-28 14:20   ` Boris Brezillon
2016-08-28 14:25     ` Ezequiel Garcia
2016-08-28 14:40       ` Daniel Golle
2016-08-28 15:00         ` Boris Brezillon
2016-08-28 15:24           ` Daniel Golle
2016-08-28 16:35             ` Boris Brezillon
2016-08-28 14:32     ` Daniel Golle
2016-08-28 14:27   ` Daniel Golle
2016-08-28 14:54     ` Ezequiel Garcia

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=20160828091017.06fc2312@gmail.com \
    --to=ralph.sennhauser@gmail.com \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=daniel@makrotopia.org \
    --cc=ezequiel@vanguardiasur.com.ar \
    --cc=hauke@hauke-m.de \
    --cc=lede-dev@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=openwrt-devel@lists.openwrt.org \
    --cc=richard@nod.at \
    --cc=wigyori@uid0.hu \
    /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