"Theodore Y. Ts'o" <tytso@xxxxxxx> writes: > As the kbuild bot has already reported, you've added an unconditional > dependency on the NLS subsystem, which is not always compiled in. > What we need to do is to add #ifdef's on CONFIG_NLS, and only support > file systems with encoding if the kernel is compiled with CONFIG_NLS. Thanks, I will address this in the next iteration. > One thought --- do we really need to use CONFIG_NLS if the encoding is > ASCII? If some use case (and Android may be one) only is interested > in supporting case-folding for ASCII, and they don't want to have the > overhead of compiling in the NLS subsystem, for ASCII couldn't use > just use strcasecmp() for its comparison function? My concern here is that the casefold and normalization operations don't make sense, semantically, when dealing with opaque byte sequences. We can assume that no-encoding means ASCII, but this is an arbitrary decision, that only make sense for english speakers. I think it is safer/less confusing to only allow this kind of operation when an explicit encoding format is in place. Is the dependency on NLS a problem for Android? I assumed it already has to enable it anyway to support fat filesystems. For use cases other than Android, I'm trying to reduce the footprint of NLS, by making it more modular (and we could even make it smaller by reducing the nls_default.c code and doing the ASCII operations algorithmically instead of using tables), such that building NLS core + ASCII should have a really tiny impact on the kernel size and build time (which I think it already does?) > The normalization for ASCII is the identify function, so it's kind of > pointless to support ASCII if we ony have case-folding support and not > normalization for now, right? Yes. the ASCII normalization is boilerplate code, in a sense, since it is just the identity function, but I'm trying to make the NLS interface generic enough to minimize how much EXT4 needs to know about encoding. Ideally, this knowledge should be left for the NLS system, in my opinion. Does it make sense? Thanks, -- Gabriel Krisman Bertazi
