Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Nov 2000 18:33:57 +0000
From:      Konstantin Chuguev <Konstantin.Chuguev@dante.org.uk>
To:        Boris Popov <bp@butya.kz>
Cc:        "Eugene M. Kim" <ab@astralblue.com>, FreeBSD Internationalization Mailing List <freebsd-i18n@freebsd.org>
Subject:   Re: Status of iconv/Unicode FFS?
Message-ID:  <3A16CB91.AABF162B@dante.org.uk>
References:  <Pine.BSF.4.21.0011181602190.19441-100000@lion.butya.kz>

next in thread | previous in thread | raw e-mail | index | archive | help
Boris Popov wrote:

> On Sat, 18 Nov 2000, Eugene M. Kim wrote:
>
> > I was wondering how far the i18n efforts on FreeBSD have gone so far,
> > especially about the kernel namespace part.
> >
> > Does anyone know about the current status of the kernel iconv library
> > and the Unicode FFS?  I would like to contribute something in this area,
> > but didn't want to reinvent the wheel. : )
>
>         I'm waiting for Konstantin to finish his iconv library tweaks.
> After this, current kernel side iconv code will be updated and can be
> committed. Michael is already working on unicode FFS.
>

I had to rewrite the library almost from scratch, to be able to use binary
tables, not modules, for CCS. I've also made some memory management
optimisations, code reusability improvements and the framework for using
built-in CCS tables and CES modules (the latter is for static library). The
library layout is finished, I'm debugging EUC code now. I suppose ISO-2022
code has bugs as well. I hope to finish everything in a few days.

Boris, I had to get rid of the module stuff written by you at the moment,
because of serious changes/simplifications in CES/CCS structure. I believe
there is no need in the module dependency tracking code anymore, as there are
no more dependencies. I still haven't got a clue how to use the library from
the kernel in terms of memory management (libc's malloc/free analogues of
kernel), module linking (dlopen/dlsym/dlclose) and memory mapping
(mmap/munmap). The current code uses these functions directly (except for
iconv_malloc). I think the best solution would be to have iconv wrappers for
these functions, using #ifdef KERNEL inside of them to call appropriate low
level functions.
I'm going to release the code together with ports (iconv-2.0). As some other
ports depend on it, this will be a good way to uncover the bugs I can't find
myself. In parallel, I can work in the kernel compatibility direction, or
anyone interested can do so.


--
        KC





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?3A16CB91.AABF162B>