Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Sep 2003 02:09:03 +0900
From:      "R. Imura" <imura@ryu16.org>
To:        freebsd-fs@freebsd.org, freebsd-i18n@freebsd.org
Cc:        sobomax@freebsd.org
Subject:   [Patch] cd9660/msdosfs/ntfs/libiconv mutli-byte extention
Message-ID:  <20030922170903.GA43754@ryu16.org>

next in thread | raw e-mail | index | archive | help
Hi all,

I made a patch for multi-byte character extension
of three file systems with enhanced LIBICONV in the
kernel. File systems are cd9660(joliet part), msdosfs,
and ntfs.

 http://www.ryu16.org/FreeBSD/kiconv/kiconv-5_current-20030921.diff

I believe this will be good news to many of the people,
such as Asian using multi-byte characters and others using
single-byte characters which FreeBSD doesn't prepare
convertion tables yet.

Currently it is only limitted to 8 bit ascii characters
convertion by LIBICONV or ports/cd9660_unicode
or external libdata/msdosfs tables.
I extented LIBICONV to handle 16 bit characters
and add new kiconv library to generate convertion tables.
If iconv(3) has a convertion rule, these file systems can use the rule.
(So, ports/cd9660_unicode and libdata/msdosfs will be obsoluted.
It also throw ports/{japanese,korean}/msdosfs away.)

Here is the summary.

New Library
 - kiconv(3)

New Kernel Options (Kernel Modules)
 - CD9660_ICONV (cd9660_iconv.ko)
 - MSDOSFS_ICONV (msdosfs_iconv.ko)
 - NTFS_ICONV (ntfs_iconv.ko)

Related Kernel Options (Kernel Modules)
 - CD9660 (cd9660.ko)
 - MSDOSFS (msdosfs.ko)
 - NTFS (ntfs.ko)
 - LIBICONV (libiconv.ko)

Related Port
 - ports/converters/libiconv

For example, with the cd9660 case, the multi-byte
character convertion will be enabled when all of
CD9660, CD9660_ICONV, and LIBICONV are specified.
When only with CD9660, it behaves as before.

kiconv(3) uses dlopen(3) to load userland iconv(3)
library and generate a character convertion table.
Then, copyin(9) the table via sysctl and kernel side
iconv(9) uses this table for character convertion.
(this is same as existent LIBICONV architecture)
If someone has much better idea or kind of enhancement,
a thing to do is only replace/add kiconv(3) and iconv(9).

Any comments? And is it possible to apply this
patch to upcoming FreeBSD-5.2?
I tested them with Japanise on i386 machine, and did make
release with i386/pc98/alpha/sparc64/ia64/amd64 via cross
building.

Note that because of bumping MODULE_VERSION of libiconv,
kern/56570 must be applied before play with this patch.
(loading smbfs will crash your system)

P.S.
Though it may be very small thing,
I think this will be one of a benefit to chose FreeBSD,
because many peple (are forced to) live with MS Windows,
and this enhancement shorten a distance between FreeBSD
and Windows environment.

Best Regards,

- R. Imura



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030922170903.GA43754>