On Thu, 29 Jul 2021 at 17:33, Ezequiel Garcia <ezequiel@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 29 Jul 2021 at 08:45, Richard Weinberger <richard@xxxxxx> 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. > Dear Eze and Richard, First of all, thank you so much for all your replies so far. Sorry, I have limited knowledge about NAND, MTD, UBI layers, but my current work involves all these so I am here. But I will surely share this information to our internal team about using ubiblock instead of mtdblock. However, I still fail to understand the problem and consequences of using mtdblock for rootfs instead of ubiblock. Last time, for my squashfs test, when I tried to replace the command line with ubiblock, I could not see any difference. How to visibly see the difference so that I can easily understand and explain the difference internally? Or, is there a document available somewhere to highlight the difference between the two? BTW, we have few raw nand partitions and few ubi volumes [including rootfs(squashfs), data(ubifs, rw)] So, I guess we should use ubiblock for all ubi volumes? Regarding Kconfig, I have few opinions. Yes, adding more description in Kconfig is a good choice. But I see that most of the time these kernel config options remains (as default) and platform developers never cares about the description. So, how to better create awareness among them, not to make these mistakes? One option is to capture these details as part of Kernel documentation. Right now when I search I could not find anything. Another option is to add a few (critical) warnings in kernel bootup logs to give some hint to the developer that there is probably something wrong. This will directly be visible to all and some developers will not like to ignore it. Or, maybe adding both options is also good. Thanks, Pintu
