Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Gero Schwäricke" <gero.schwaericke@sevenlab.de>
To: <buildroot@buildroot.org>
Cc: <yann.morin.1998@free.fr>
Subject: [Buildroot] fs/ubi: UBI/UBIFS option sharing
Date: Wed, 16 Jul 2025 15:17:14 +0200	[thread overview]
Message-ID: <DBDIB94NTTBS.3LVPF0F3PQ86M@sevenlab.de> (raw)

Hi,

I stumbled upon the following inconsistency regarding UBI/UBIFS:

fs/ubi/ubi.mk uses the option BR2_TARGET_ROOTFS_UBIFS_MINIOSIZE from
fs/ubifs/Config.in. This assumes that if you're building a UBI image,
you are also building a ubifs rootfs. That's not always the case. I
stumbled upon this when building a ubi image with a squashfs rootfs.

There are:

- PEBSIZE   (in ubi)
- SUBSIZE   (in ubi)
- MINIOSIZE (in ubifs)
- LEBSIZE   (in ubifs)

PEBSIZE, SUBSIZE, MINIOSIZE are all inputs from the flash layout.
LEBSIZE is based on these inputs and is the block size for all FS that
need to fit into the UBI image (rootfs or not).

I think this is a leftover from the migration from a combined
ubifs-in-ubi-image approach to the separate ubi and ubifs filesystems in

  9fc21664e8 (fs/ubifs: spin-off ubi to be its own filesystem, 2017-12-28)

Currently we're just building the ubifs rootfs und don't use. It's not a
huge deal, it clutters the config a little and takes a few seconds
longer to build.

I wonder what a better solution could look like. Here are some ideas:

1. Move MINIOSIZE and LEBSIZE to ubi/Config.in.
2. Create a NAND support option in fs/Config.in with the NAND parameters
   that ubi and ubifs can depend on.
3. Remove fs/ubi entirely and use ubinize like genimage.

Granted, any of these would require all users of fs/ubi and/or fs/ubifs
to do a major migration. So maybe option 4. leave everything as is? :)

Any thoughts on this?

Best,
Gero
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

                 reply	other threads:[~2025-07-16 13:17 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=DBDIB94NTTBS.3LVPF0F3PQ86M@sevenlab.de \
    --to=gero.schwaericke@sevenlab.de \
    --cc=buildroot@buildroot.org \
    --cc=yann.morin.1998@free.fr \
    /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