On Tue, Apr 27, 2021 at 11:06:33AM -0400, Gabriel Krisman Bertazi wrote: > > I think the better argument to make is just one of simplicity; > > separating the Unicode data table from the kernel adds complexity. It > > also reduces flexibility, since for use cases where it's actually > > _preferable_ to have Unicode functionality permanently built-in the > > kernel, we now force the use of some kind of initial ramdisk to load a > > module before the root file system (which might require Unicode > > support) could even be mounted. > > FWIW, embedding FW images to the kernel is also well supported. Making > the data trie a firmware doesn't make a ramdisk more of a requirement > than the module solution, I think. I don't think we support building firmware directly into the kernel any more. We used to, but IIRC, there was the feeling that 99.99% of the time, firmware modules were not GPL compliant, and so we ripped out that support. So my point was with the module support, it's *optional* that it be compiled as a module, which is convenient for those use cases, such as for example a mobile handset --- where there is no need for modules since the hardware doesn't change, and so modules and an initrd is just unnecessary complexity --- and firmware, which would make an initial ramdisk mandatory if you wanted to use the casefold feature. Put another way, the only reason why putting the unicode tables in a module is to make life easier for desktop distros. For mobile handsets, modules are an anti-feature, which is why there was no call for supporting this initially, given the initial use case for the casefold feature. Cheers, - Ted
