On Thursday 02 January 2020 09:30:29 Pali Rohár wrote:
> On Thursday 02 January 2020 15:06:16 Namjae Jeon wrote:
> > > > +static const struct fs_parameter_spec exfat_param_specs[] = {
> > > > + fsparam_u32("uid", Opt_uid),
> > > > + fsparam_u32("gid", Opt_gid),
> > > > + fsparam_u32oct("umask", Opt_umask),
> > > > + fsparam_u32oct("dmask", Opt_dmask),
> > > > + fsparam_u32oct("fmask", Opt_fmask),
> > > > + fsparam_u32oct("allow_utime", Opt_allow_utime),
> > > > + fsparam_string("iocharset", Opt_charset),
> > > > + fsparam_flag("utf8", Opt_utf8),
> > >
> > > Hello! What is the purpose of having extra special "utf8" mount option?
> > > Is not one "iocharset=utf8" option enough?
> > utf8 nls_table supports utf8<->utf32 conversion and does not support
> > surrogate character conversion.
>
> So in other words, this is just subset of UTF-8 just to 3 byte long
> sequences (for Unicode code points up to the U+FFFF).
Anyway, this is limitation of kernel's NLS framework? Or limitation in
current exfat driver implementation?
Because if it is in kernel's NLS framework then all kernel drivers would
be affected by this limitation, and not only exfat.
--
Pali Rohár
pali.rohar@xxxxxxxxx
