> >> On the other hand, we might want locale support in the kernel, in case
> >> we ever end up supporting EBCDIC.
> 
> >Is it me, or is this just plain silly? (1/2 :-)
> 
> It's mostly silly.

I think EBCDIC support is silly, too, and it is hardly worth the effort.
IMHO, All supported character-set should be upper compatible with ASCII,
this requirement dramatically reduces the cost of implementation.

> Maybe most of them  (all of them?) won't be kernel issues.  Cool.  But just
> in case, we should start thinking about it.

Probably most of them, not all. 
e.g. SVR4 has STREAMS modules which supports multi-byte character-set 
     editing in tty ICANON mode.

> Plan 9 has demonstrated that it's possible to have a small system which
> uses 16 bit values for characters.  I think we should consider being ready
> for this one.

IMHO, 16bit character-set is not sufficient, and 32bit character-set is
needed for many compatibility reasons. 
- UNICODE standard (UTF8) requires it.
- Most of modern UNICES support 32bit character-set
- Taiwanese EUC character-set requires 32bit character
- ...
But unlike Plan9, I think it is user-level issues (or at least most 
of them are user-level issues), and it should be handle by I18N framework.
i.e. Kernel and user-level code should have general way to handle many
character-sets, and UNICODE (UTF8) should be supported as one of it.
--
soda@sra.co.jp		Software Research Associates, Inc., Japan
(Noriyuki Soda)		   software tools and technology group