On Sun, Apr 16, 2023 at 8:26 PM Theodore Ts'o <tytso@xxxxxxx> wrote: > > On Sat, Apr 15, 2023 at 10:56:23PM -0700, Christoph Hellwig wrote: > > On Sun, Apr 16, 2023 at 07:47:42AM +0200, Christoph Hellwig wrote: > > > We could do that, but it seems a bit ugly. What prevents symbol_request > > > from working properly for this case in your setup? > > > > To anwer to myself - I guess we need something else than a plain > > EXPORT_SYMBOL for everything that is used by > > symbol_request. Which would be a nice cleanly anyway - exports for > > symbol_request aren't normal exports and should probably have a clear > > marker just to stand out anyway. > > Agreed, that's the best/cleanest long-term solution. > > The short-term hack that William could use in the interim would be to > simply configure CONFIG_UNUSED_KSYMS_WHITELIST to include > 'utf8_data_table', which will solve his immediate problem without > needing to maintain an out-of-tree patch in his kernel. > > Presumably, that's what the long-term solution would effectively do, > except it would be automated as opposed to requiring people who use > CONFIG_TRIM_UNUSED_KSYMS to have to do manually. Note also that there > are only a half-dozen or so such symbols in the Linux kernel today, so > while we could and probably should automate it, it's not clear to me > the number of use cases where CONFIG_TRIM_UNUSED_KSYMS is going to be > relevant are very likely quite small. (The only ones I can think of > are the Android Generic Kernel Image and for enterprise Linux > distributions. And in both cases, I suspect those use cases will > probably have a very large list of symbol added to the allow list, so > adding those few extra symbols is probably going to be in the noise. > > - Ted Thanks for the responses! I was missing the part that utf8-core.c is always built into the kernel when CONFIG_UNICODE is enabled. So it makes sense to me why we need to use symbol_request() vs just EXPORT_SYMBOL. It should be fine for us to include this symbol in our symbol list. Thanks, Will
