Please tell me again just where the Linux-kernel proper needs to pay
attention to specific encodings?
I realize the need to transcribe filenames for "foreign" filesystems
mounted on Linux. E.g., DOS/Windows filesystems need to transcribe to
deal with "/" vs. "\"; there are similar problems for Mac filesystems
that permit any character in a filename.
If some other OS conventionally stores its filenames as EBCDIC, or XXX
flavor of Unicode, or something else, it makes sense for the module for
*that filesystem* to be able to convert filenames to and from some
"Linux-native" encoding such as ASCII or (hypothetically) Unicode, or
(possibly) something else. Is there any other situation where the kernel
should care about the encoding?
This filesystem-specific translation could be done by default, or at least
by some option specified at mount-time; I suppose you should be able to
tell the filesystem to let (say) its raw EBCDIC filenames through as much
as possible. However, outside that limited scope, is there any reason why
the kernel should bother to identify and translate between encodings?
If not, maybe it would be best to restrict the discussion to the scope
it deserves. For instance, the question would be completely irrelevant
for kernel internals, for all native filesystems, and for most (?)
existing foreign filesystems as well.
That's not to say that it's not an important question. But I don't
see any concrete suggestions on how to satisfy anyone's needs. What
mount options would Alex Belits want for a Java-OS filesystem that used
16-bit Unicode?
Bruce
-- You are the lens of the world: the lens through which the world may become aware of itself. The world, on the other hand, is the only lens in which you can see yourself. It is both lenses together that make vision. (--R. A. MacAvoy)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu