[PATCH/RFC 0/3] UBI: unify mouting rootfs based on cmdline parameter

[Daniel Golle]

Hi Richard,

On Sun, Aug 28, 2016 at 11:28:18AM +0200, Richard Weinberger wrote:
> Ralph,
> 
> On 28.08.2016 11:19, Ralph Sennhauser wrote:
> >>> 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.  
> >>
> >> When your minimal initramfs consumes 300KiB you're doing something
> >> wrong. As I said in another thread, for your special purpose you'd
> >> need to create a minitmal userspace for initramfs, no fancy (eg)libc,
> >> just a bare minimum /init program which does the mount probing.
> >> Shouldn’t be more than a few system calls.

That would indeed be nice, however, I fail to see how this can work
with little effort *before* having devtmpfs ready. Also, we'll need a
non-standard kernel parameter (usually "real_root=") to pass the
selected rootfs down to our to-be-implemented micro-sized initramfs.

> >>
> >> Thanks,
> >> //richard
> > 
> > Well, I use busybox because I'm lazy and still get away with only 300Kb.
> > And as I said there is plenty space on my device. (6M per uImage OEM
> > firmware configuration)
> 
> So, problem solved. Use an initramfs. :-)

I agree this might be acceptable for some, but certainly not all
cases. Unlike to your previous statement, I'm not generally opposed
to having an initramfs included in the kernel as that can also provide
other nice features such as recovery/failsafe methods.
We've had this discussion before and my goal is, as I explained, to
make the kernel as reusable as possible and even allow people to use
OpenWrt/LEDE's kernel binary with other distributions. I'm sure
this is also possible when using an initramfs, however, I still fail to
see the necessity for that on simple devices.
Imho, using an initramfs shouldn't be mandatory which is why there are
patches (now down to about 80 LoC, resulting in probably less than 1kB
in added binary size) to mount the rootfs without the need of an
initramfs, simply because I do not consider that to be a
"complex setup" if there is no less complex and yet generic way
imaginable to boot on that platform at all.
Hence I'm not buying the argument that ubiX_Y and ubiblockX_Y are two
different devices and thus, this is a device selection problem and thus
initramfs is the recommended way -- in fact, all other filesystems
which do *not* build upon a block device provide some probing hacks in
early userspace. Take MTD as an example: mtdblock devices are
automagically provided and needed for block-based filesystems, no need
for initramfs or kernel parameters to achieve that. For UBI, ubiblock
(or gluebi...) is required to use UBI for anything else than UBIFS.
Anyway, I'm afraid you have made your decission and additional
arguments have no influence what-so-ever.

> 
> </discussion>,

If that's the whole answer ("Use initramfs. End of story."), that's
pretty disappointing. Dispite your previous invitation to discuss the
matter and collaborate to address the needs of all parties involved,
you are now offering only one option which is not agreeable by all
parties (which is the obvious reason for those nasty patches to exist
in first place). Carrying a few patches in our local overlay doesn't
truly hurt in a technical sense, however, it'd be nicer to discuss how
those features could be brought upstream or mitigate our local patches
in other ways.
In the case of not finding room for a debate and your answer is a
straight "we don't want this feature upstream" this is never the less
a good reference to remember when touching those patches in future:
falls into "we tried, they didn't want it" and thus we'll keep carrying
them around, at least as long as there are platforms needing them.


Cheers


Daniel

> //richard