linux-kernel - Re: MTD: How to get actual image size from MTD partition

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 20 Aug 2021 23:54:50 +0530
From:   Pintu Agarwal <pintu.ping@...il.com>
To:     Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
Cc:     Richard Weinberger <richard@....at>,
        Kernelnewbies <kernelnewbies@...nelnewbies.org>,
        Greg KH <greg@...ah.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-mtd <linux-mtd@...ts.infradead.org>,
        Sean Nyekjaer <sean@...nix.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        Phillip Lougher <phillip@...ashfs.org.uk>
Subject: Re: MTD: How to get actual image size from MTD partition

On Thu, 29 Jul 2021 at 22:41, Pintu Agarwal <pintu.ping@...il.com> wrote:
>
> On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia
> <ezequiel@...guardiasur.com.ar> wrote:
> >
> > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger <richard@....at> wrote:
> > >
> > > Ezequiel,
> > >
> > > ----- Ursprüngliche Mail -----
> > > > [snip]
> > > >
> > > > Ouch, so surprised that after all these years someone is doing squashfs/mtdblock
> > > > instead of using ubiblock :-)
> > > >
> > > > Can we patch either Kconfig or add some warn_once on mtdblock
> > > > usage, suggesting to use ubiblock instead?
> > >
> > > a hint in Kconfig makes IMHO sense. Do you want to send a patch?
> > > A warning is too much since on some tiny embedded system with NOR flash mtdblock is still
> > > a good choice.
> > > ubiblock is mostly useful for NAND flash.
> > >
> > > > I remember there was still some use case(s) for mtdblock but I can't remember
> > > > now what was it, perhaps we should document the expectations?
> > > > (Is that for JFFS2 to mount?)
> > >
> > > a long time ago mount didn't accept character devices, so you had to pass mtdblockX to mount
> > > JFFS2.
> > > This limitation is gone.
> > >

Hi,

Just a further follow-up on this discussion.
Whether to use /dev/mtdblock or /dev/ubiblock for rootfs (squashfs)
mounting during boot.

As suggested here:
Instead of using this in kernel command line:
[    0.000000] Kernel command line: ... rootfstype=squashfs
root=/dev/mtdblock44 ubi.mtd=40,0,30 ...

I used this:
[    0.000000] Kernel command line: ... rootfstype=squashfs
ubi.mtd=40,0,30 ubi.block=0,0 root=/dev/ubiblock0_0 ...

The device is booting fine with ubiblock as well.
But, per say, I could not find any visible difference.
I just observed a slight improvement in boot time, but I need to
double-check on this, with few more reboot cycles.

Apart from this what are the other visible benefits of using ubiblock
which can be explained to be management or internal team ?
I could not find any documentation explaining the difference, except this one:
http://www.linux-mtd.infradead.org/doc/ubi.html#L_ubiblock

Can someone also point me to the respective driver code in case of
using /dev/mtdblock and /dev/ubiblock ?
Apart from theory I also want to check the impact at the code level..

Thanks,
Pintu