Re: [Buildroot] [PATCH 1/1] fs/squashfs: add more options to customize creation

["Yann E. MORIN" <yann.morin.1998@free.fr>]

Linus, Al,

On 2022-05-16 01:56 +0200, Linus spake thusly:
> I have already prepared the patch for blocksize, using choices
> from 4k, 8k, ..., 512k, 1024k. That one should be pretty straight
> forward.
> 
> I also find 1k to be pretty ridiculous. Not even sure if it would
> work. This size seems to be pretty old and also only start at 4k:
> https://tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html

Yes, 1K and 2K are not suported, but that page is about mksquashfs 3.x,
which supported from 4K to 128K, but we are now packagng 4.5, which
supports from 4K to 1M.

> I've used the same style that was used for specifiying the compression.
> Not sure whether the later string without a name is hidden,

Yes, it should be hidden, i.e. have no prompt, because the actual user
input is the entry in the choice; the hidden string is just a
translation from a multi-boolean to a the actual size. We have such
constructs in a few opther places. For example, see the version choice
for the kernel version;

      129 config BR2_LINUX_KERNEL_VERSION
      130     string
      131     default "5.17.7" if BR2_LINUX_KERNEL_LATEST_VERSION
      132     default "5.10.104-cip3" if BR2_LINUX_KERNEL_LATEST_CIP_VERSION
      133     default "5.10.104-cip3-rt3" if BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION
      134 ...

> but I've
> so far never encountered that. I can add this of course if this has
> some benefit (maybe being able to specify a specific size in raw
> config values??).

Nope, the choice is the only way to set it.

> ## Compression
> 
> For the compression arguments, I'm up to anything here as well.
> I'm not sure if we should use all extreme options by default
> 
> >Also note that lz4 already uses -Xhc unconditionally, and commit
> >     07e37bcc42f notes that an extra option was dropped, so maybe we
> >     should just unconditionally enable all those options when possible?
> Seems like a easy way to confuse people or cause errors should
> a option somehow make problems.

In that case, people would not enable this option if it is causing issue
for them.

> Or is it a major problem to break
> the assumption that only lz4 is already optimized?

Well, to keep the existing behaviour we could do something like:

    config BR2_TARGET_ROOTFS_EXTREME_COMP
        bool "extreme compression if possible"
        default y if BR2_TARGET_ROOTFS_SQUASHFS4_LZH

> >   - for the comnpression options, I think a generic boolean would be
> >     better:
> I agree with that. Will try to get this done tomorrow and do a couple
> of tests to ensure there are no obvious problems.
> 
> ## In conclusion
> 
> If that's okay with you I can prepare a patch-set tomorrow and
> send them in for review (hopefully also tomorrow).

Yes, no worries, as you can make it. Thanks!

Regards,
Yann E. MORIN.


-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot