Re: [PATCH 1/2] ubi: mount partitions specified in device tree

Daniel,

Am 19.06.2016 um 13:25 schrieb Daniel Golle:

Hi Richard,

On Sun, Jun 19, 2016 at 10:53:42AM +0200, Richard Weinberger wrote:

quoted

Am 19.06.2016 um 01:20 schrieb Daniel Golle:

quoted

In MBR there used to be an 'active' flag stored for each partition.
Maybe it'd be nice to introduce something similar to mark UBI volumes
to be the default rootfs.
Currently we solve this issue by convention: If a volume is named
'rootfs' it is automatically mounted during boot. Depending on the
filesystem in use a ubiblock device has to be created as well.
This is mostly just the continuation of the existing naming convention
of mtd partitions, a patch OpenWrt is carrying around for a long
while already.
To support the same on UBI, another set of patches was made.

Sorry, I still have troubles to understand your use case.
Both of you seem to hate the kernel command line for reasons
I don't fully understand so far.

I like the kernel command line a lot :)
And *being the end-user* I like to be the one defining and modifying it
according to my current needs. For that reason I do *not* like firmware
bootloaders to prepend/append or even overwrite the cmdline for things
like selecting the rootfs, because usually that restricts the use of
the relevant parameters by device owners.
Imagine: The device runs a bootloader which already sets rootfs= or
overwrites the cmdline of the stock firmware. How will an end-user
who cannot change the bootloader use an alternative OS which uses e.g.
a USB pendrive as it's rootfs? This is why we end up with things like
renaming kernel cmdline parameters in alternative firmware projects,
e.g. rootfs2=...., so end-users can re-gain access to cmdline
parameters augmented by the bootloader.

So, the use case is being able to use a custom OS on a "locked"
device where the bootloader hates you?

But you still can override the cmdline supplied by the bootloader
by adding your cmdline into the device tree, right?

For that reason I believe that using the cmdline to pass
*non-user-defined* details from the bootloader to the kernel is just
not such a nice thing to do.

Well, this is not how the cmdline works. We don't have such
an separation.
Some distros use hacks such as "showopts" to have such a split.

quoted

quoted

I agree that there should be a way to pass this through the of_node
of the mtd partition which is defined in the device tree.
Selecting to-be-ubi-attached mtd partitions in device-tree would
replace patch:

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/490-ubi-auto-attach-mtd-device-named-ubi-or-data-on-boot.patch

What is the need of this? Use use the kernel command line to tell UBI from which MTD to attach.

The same kernel gets used on many devices having different $vendor
mtd-partition layouts. A way other than the kernel cmdline allows
to specify the default behaviour without restricting the user to
manually use those cmdline options.

You can put the cmdline into the per-device device tree.
This is the concept of a multi-device kernel. One kernel and
many device trees.

quoted

quoted

To auto-select the rootfs, we currently carry another bunch of patches

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/491-ubi-auto-create-ubiblock-device-for-rootfs.patch

Same question here.

quoted

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/492-try-auto-mounting-ubi0-rootfs-in-init-do_mounts.c.patch

Ditto.

quoted

https://git.lede-project.org/?p=source.git;a=blob;f=target/linux/generic/patches-4.4/493-ubi-set-ROOT_DEV-to-ubiblock-rootfs-if-unset.patch

Ditto.

Same arguments as above. In addition, we do not want to hard-code the
filesystem type used for the rootfs volume, as it can either be UBIFS
or a read-only filesystem needing a ubiblock device. Thus we would
need the bootloader to know which filesystem *type* is being used and
then decide wether to pass 'rootfs=ubiX:Y' or
'ubiblock=... rootfs=/dev/ubiblock0'.

What is wrong with having a very minimal initramfs to do such an
auto discovery logic?

quoted

quoted

This is more or less filesystem-agnostic and works fine as long as
there is only one volume called 'rootfs' and this volume is always
used as rootfs.

Dual-boot setups will need some way to pass the active rootfs volume to
the kernel. While I agree that this is possible by appending or
prepending to the cmdline string passed to the kernel, this either
limits the users' ability to manually specify the rootfs using the
cmdline or becomes a more complex task to only append/prepend the
cmdline in case the user-defined string doesn't already contain
relevant parameters...

Sorry, but this is just a tooling problem and not to be addressed in the kernel.
There is also the possibility to use an initramfs (either as file or embedded in the kernel)
if the mount/attach logic becomes *really* complicated...

quoted

Thus it'd be nicer to flag the default rootfs volume via the device-
tree.

As I said, as far I'm informed device tree is for configuring Linux, it describes
the hardware. We also don't have LVM, DM or iSCSI bindings in DT. ;)
Maybe device tree folks will tell more...

But we do have MTD and MTD partitions in DT. To me it'd feel more
consistent if MTD devices, partitioning and which MTD partition(s) to
use as UBI would be defined in the same place.

This is something you need to discuss wit DT folks.
I'm not per se against UBI DT bindings it just does not feel right
and contradicts my understanding of it.

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html