[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAEAJfDDtGcUquyP7Jn0Urttt4kSfAQbJ_qPQ90ROtWLavW9EA@mail.gmail.com>
Date: Thu, 29 Jul 2021 09:03:26 -0300
From: Ezequiel Garcia <ezequiel@...guardiasur.com.ar>
To: Richard Weinberger <richard@....at>
Cc: Pintu Agarwal <pintu.ping@...il.com>,
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 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.
>
OK, let me try to cook a patch for you.
Eze
Powered by blists - more mailing lists