Date: Sun, 28 May 2000 12:11:20 +0700 (ALMST) From: Boris Popov <bp@butya.kz> To: "Eugene M. Kim" <ab@astralblue.com> Cc: Alexander Voropay <a.voropay@globalone.ru>, freebsd-i18n@FreeBSD.ORG Subject: Re: i18n in FreeBSD Message-ID: <Pine.BSF.4.10.10005281139540.11154-100000@lion.butya.kz> In-Reply-To: <Pine.BSF.4.20.0005261007400.97660-100000@home.astralblue.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 26 May 2000, Eugene M. Kim wrote: > | In addition, I've wrote kernel side iconv-like interface which > | uses libiconv library to construct recode tables. Currently, each > | filesystem (msdosfs, nwfs, smbfs) uses its own recode tables even if they > | are the same. > > That said, I think this probably needs to be dealt with prudently, > because anything related to kernel namespace manipulation tends to lead > to a confusion. That holds true esp. in such a grey area like charset > issues. There are tons of issues that must be addressed, like case > folding in filenames, how to deal with locale issues (e.g. different This is filesystem dependent. > users on the system may use different locales; are we implementing a > locale-sensitive namespace, and if yes, how?), and most important, how And this too. Those questions are more related to the design of particular filesystem and has no relation to the iconv interface. > existing implementations have done the job (e.g. msdosfs, smbfs, > cdfs/Joliet and so on). Currently each filesystem keeps its own conversion tables, no one of the known filesytem deal with user's locale settings (and this is reasonable enough in the present kernel environment). The kernel iconv interface exposes the same functions as its user land counterpart. The conversion schemes can be uploaded to kernel only by the root user. Each scheme has 'from' and 'to' name, for example: koi8-r cp866 cp866 koi8-r koi8-r toupper koi8-r tolower koi8-r unicode unicode koi8-r ..., etc. When, say, mount_smbfs command issued, it can look up an already present schemes and/or add new ones. Each scheme can be used by different filesystems and other kernel subroutines. Various conversion schemes may use various drivers. Currently there are two types of drivers: table(XLAT) and unicode(ucs). XLAT driver used for schemes which will fit into single 256 (512) bytes table. New tables can be constructed dynamically and uploaded to the kernel. UCS drivers placed into KLDs and has no userland interface. I.e. they register all 'from'-'to' combinations on loading. The iconvdriver interface is open and new types of drivers can be created if needed. In the next two weeks I'll try to post a proposal to the arch@ list. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.10005281139540.11154-100000>