This is a multi-part message in MIME format.
--------------342006B00CDDEEC2777CCC7D
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

 
--------------342006B00CDDEEC2777CCC7D
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Message-ID: <3831807E.826A3338@ics.muni.cz>
Date: Tue, 16 Nov 1999 17:04:14 +0100
From: Jaromir Dolecek <dolecek@ics.muni.cz>
Reply-To: dolecek@ics.muni.cz
MIME-Version: 1.0
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
Subject: Re: codeset recoding engine
References: <199911161552.KAA02761@Twig.Rodents.Montreal.QC.CA>
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: 7bit

der Mouse wrote:
> One person's bloat isn't necessarily another's.
> 
> I sure don't want to have to pay the penalty for permanently resident
> large tables just to support the one or two occasions when I want to do
> something with such-and-such a filesystem; I'd much rather pay a larger
> penalty in userland, when it's needed, than pay the smaller (but still
> relatively large) penalty in the kernel all the time.
> 
> For people whose process mix includes several processes doing such
> access regularly, of course, the tradeoff goes the other way.

The codeset tables can easily be made LKMable. That would kind of solve
the "sometimes needed" issue. Note that large tables are needed
only for really big codesets, such as eucjp. The files implementing
recoding for iso-8859-1, iso-8859-2 and koi8-r are from 800B
to 2KB each compiled, so no big deal at all and significantly less
that any of filesystems in question (cd9660 & ntfs).

If the kernel would need to do conversion anyway (it
would convert the Unicode to UTF-8 encoding), why not directly
recode the name to user-encoding ?

Jaromir

--------------342006B00CDDEEC2777CCC7D--