* vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there?
@ 2011-09-02 11:27 Amit Sahrawat
2011-09-03 9:09 ` NamJae Jeon
0 siblings, 1 reply; 4+ messages in thread
From: Amit Sahrawat @ 2011-09-02 11:27 UTC (permalink / raw)
To: linux-kernel; +Cc: linkinjeon
>From my opinion both should support the same functionality as the
motive behind this seems to introduce the complete support for utf8.
But, I am surprised to see the behavior changes in the ‘2’ options.
1) When using iocharset=”utf8” it makes vfat case sensitive, while
this is not the case with using utf8=1
2) Surrogate pair don’t work when using iocharset=”utf8”, because that
traverses a path like this:
xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32()
After this it returns EINVAL because Surrogate pair correct code is
greater than 0xFFFF (MAX_WCHAR_T – limit which is put)
But this is not the case with utf8=1
There are other places also where I can see usage different due to
usage of char2uni()
Can someone provide any help on this? Why do we have separate options
for using utf8 and if utf8=1 smoothly supports proper working then why
not discard iocharset=”utf8” ? and if this is not the case
why was utf8=1 introduced?
Please provide any guidance in this.
Thanks & Regards,
Amit Sahrawat
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there? 2011-09-02 11:27 vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there? Amit Sahrawat @ 2011-09-03 9:09 ` NamJae Jeon [not found] ` <87hb4tvoth.fsf@devron.myhome.or.jp> 0 siblings, 1 reply; 4+ messages in thread From: NamJae Jeon @ 2011-09-03 9:09 UTC (permalink / raw) To: Amit Sahrawat, hirofumi; +Cc: linux-kernel 2011/9/2 Amit Sahrawat <amit.sahrawat83@gmail.com>: > From my opinion both should support the same functionality as the > motive behind this seems to introduce the complete support for utf8. > But, I am surprised to see the behavior changes in the ‘2’ options. > 1) When using iocharset=”utf8” it makes vfat case sensitive, while > this is not the case with using utf8=1 > 2) Surrogate pair don’t work when using iocharset=”utf8”, because that > traverses a path like this: > xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32() > After this it returns EINVAL because Surrogate pair correct code is > greater than 0xFFFF (MAX_WCHAR_T – limit which is put) > But this is not the case with utf8=1 > There are other places also where I can see usage different due to > usage of char2uni() > > Can someone provide any help on this? Why do we have separate options > for using utf8 and if utf8=1 smoothly supports proper working then why > not discard iocharset=”utf8” ? and if this is not the case > why was utf8=1 introduced? > > Please provide any guidance in this. > > Thanks & Regards, > Amit Sahrawat > I also am wondering this issue for long time. May be, Ogawa will know well. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <87hb4tvoth.fsf@devron.myhome.or.jp>]
* Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there? [not found] ` <87hb4tvoth.fsf@devron.myhome.or.jp> @ 2011-09-05 0:04 ` NamJae Jeon [not found] ` <87y5y3zuc5.fsf@devron.myhome.or.jp> 0 siblings, 1 reply; 4+ messages in thread From: NamJae Jeon @ 2011-09-05 0:04 UTC (permalink / raw) To: OGAWA Hirofumi; +Cc: Amit Sahrawat, linux-kernel 2011/9/3 OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>: > NamJae Jeon <linkinjeon@gmail.com> writes: > >> 2011/9/2 Amit Sahrawat <amit.sahrawat83@gmail.com>: >>> From my opinion both should support the same functionality as the >>> motive behind this seems to introduce the complete support for utf8. >>> But, I am surprised to see the behavior changes in the ‘2’ options. >>> 1) When using iocharset=”utf8” it makes vfat case sensitive, while >>> this is not the case with using utf8=1 >>> 2) Surrogate pair don’t work when using iocharset=”utf8”, because that >>> traverses a path like this: >>> xlate_to_uni()-->nls->char2uni()-->char2uni()-->utf8_to_utf32() >>> After this it returns EINVAL because Surrogate pair correct code is >>> greater than 0xFFFF (MAX_WCHAR_T – limit which is put) >>> But this is not the case with utf8=1 >>> There are other places also where I can see usage different due to >>> usage of char2uni() >>> >>> Can someone provide any help on this? Why do we have separate options >>> for using utf8 and if utf8=1 smoothly supports proper working then why >>> not discard iocharset=”utf8” ? and if this is not the case >>> why was utf8=1 introduced? >>> >>> Please provide any guidance in this. >>> >>> Thanks & Regards, >>> Amit Sahrawat >>> >> >> I also am wondering this issue for long time. >> May be, Ogawa will know well. > > History is simple. There already was the utf8 option before nls utf8 > module was introduced. And utf8 was introduced for other of FAT. > > Well, it doesn't provide case letter conversion table for some > reasons. But, FAT requires conversion table. For utf8 option, it > emulates the case conversion by using tables in iocharset= or nls= nls > module. > > NLS infrastructure has several limitation, and to support encoding > conversion and case letter more fully, it would be better to introduce > new infrastructure. But it would need not small change. > > Thanks. > -- > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> > Hi. Ogawa. If the user to use FAT first time, they are confused about this option, or they may use only iocharset without knowing the utf8 option(there is case sensitive issue). If nls_utf8 is improved such as adding upper/lower case translation table, supporting surrogate pair etc.., I want to know whether you can integate only iocharset=utf8 with removing utf8 option. If done like above my suggetion, user can use only option(iocharset=utf8) without confusing. Thanks. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <87y5y3zuc5.fsf@devron.myhome.or.jp>]
* Re: vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there? [not found] ` <87y5y3zuc5.fsf@devron.myhome.or.jp> @ 2011-09-05 4:39 ` NamJae Jeon 0 siblings, 0 replies; 4+ messages in thread From: NamJae Jeon @ 2011-09-05 4:39 UTC (permalink / raw) To: OGAWA Hirofumi; +Cc: Amit Sahrawat, linux-kernel 2011/9/5 OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>: > NamJae Jeon <linkinjeon@gmail.com> writes: > >> I want to know whether you can integate only iocharset=utf8 with >> removing utf8 option. > > I guess *I* will not do, because I don't have time (and maybe > motivation) to concentrate it. > > Furthermore, even if I had time, I think I will not use current options > anymore. Instead, I will add new infrastructure like we can support more > flexible (like kiconv? on freebsd). And I suppose the both > infrastructures (and options) will be used until it is completely > migrated. > > Thanks. > -- > OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> > Thanks for your reply. I have a question. Do you know who is nls maintainer ? I can not find it in MAINTAINERS file. Thanks. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2011-09-05 4:39 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-02 11:27 vfat filesystem: Why utf8=1 when iocharset=”utf8” was already there? Amit Sahrawat 2011-09-03 9:09 ` NamJae Jeon [not found] ` <87hb4tvoth.fsf@devron.myhome.or.jp> 2011-09-05 0:04 ` NamJae Jeon [not found] ` <87y5y3zuc5.fsf@devron.myhome.or.jp> 2011-09-05 4:39 ` NamJae Jeon
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.