[mouse]
>>> Changing msdosfs to use UTF-8 would break msdosfs for people
>>> happily using ISO-8859-1, however.
[jdolecek]
>> So?  It doesn't seem to bother you to break FFS for people using it
>> for other than UTF-8; why is this any different?
[Pavel Cahyna <pavel.cahyna@st.mff.cuni.cz>]
> Maybe I didn't follow this discussion closely enough, but did Jaromir
> propose to do this (breaking FFS for people using it for other than
> UTF-8)?

I'm not certain - but someone did, and it seemd to me that Jaromir was
arguing in favour of it.

Specifically, the proposal as I saw it was to declare, by fiat, that
the user<->kernel ABI would operate on UTF8-encoded character
sequences, rather than the octet sequences we have today - which of
course would affect (the userland interface to) all filesystems in use.
Including FFS, if any are mounted.

> I see that UTF-8 has been proposed by Jason Thorpe in
> <F04E64F3-3A41-11D9-8F47-000A957650EC@shagadelic.org> as the encoding
> for the system call layer, but maybe the intent was to enforce it
> only for filesystems that need it?

Maybe.  But if so, whoever meant that has done an extremely poor job of
communicating that intent, not only in the proposal but in the failure
to correct the misreading of it.  What you describe is, as I understand
it, exactly what I think should be done, and what I think is done
today: the ABI encoding, if any, is determined by the filesystsem
responsible for the pathname component in question: the FS-independent
interfaces are agnostic on not only what encoding is in use but also
_whether_ an encoding is in use - on whether a filename component is an
octet sequence or a character sequence.  (After all, the intent behind
a filename is something that software often cannot determine.)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B