I just would like to add a few things.
Narayana is already working on the support of PCFS LFN Unicode <-> UTF-8
so that all UTF-8 locales and environments will be able to see
non-ASCII characters. Related PSARC cases are:
PSARC 2005/428 PCFS support of non-ASCII filenames
PSARC 2005/446 Unicode encoding conversion functions at the kernel
The 2005/446 is defined as Consolidation Private interfaces but I'm
hoping to change/promote that to Committed interfaces. (I think I owe
at least that much to Frank.)
Related to this but not 100% so, there is also kernel side code conversion
support being developed within Sun. This project will support code
conversions between majority of well-known/used codesets and UTF-8.
I'm still hoping that we could work on transparent code conversions at
libc so that people will use Unicode at file systems and yet such Unicode
will be transparently converted to user land whatever codeset that
people are using at their environment as the user locale. I think I forwarded
the URL before but just in case, the idea is described in the following
PDF file, esp. slide pages 15-25:
http://developers.sun.com/techtopics/global/products_platforms/solaris/reference/presentations/IUC29-FileSystems.pdf
Ienup
Roland Mainz wrote at 11/29/06 16:46:
Joerg Schilling wrote:
Roland Mainz <[EMAIL PROTECTED]> wrote:
[CC:'Ing Ienup Sung that someone from the i18n folks is aware of the
discussion]
If you add this please consider two three options here:
1. Conversion to the system's default locale (this should be the
default)
2. Conversion to UTF-8
3. Conversion to a defined encoding (encoding=<encodingidetifer>)
This would create the demand for an in-kernel iconv.
Yes... and an in-kernel way to figure-out which locale is used by the
system (or... maybe "mount_pcfs" can pass the value to the kernel
module) ...
I am already waiting for it for better Joliet support in hsfs.
Anybody interested in writing a new, free and kernel aware iconv?
Yes and no. I would prefer to keep the first implementation
"pcfs"-private and then work on improving it...
----
Bye,
Roland
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
