rv = acpi_eval_string(aa->aa_node->ad_handle,
			    "_STR", &str);
			if (ACPI_SUCCESS(rv)) {
				aprint_normal("[%s] ", str);

I am guessing the answer is "no" - that there isn't anyone who has seen
this code successfully print a device identification string from the DSDT.

The value of _STR is in UTF-16. The first byte (if littleendian, or else
the second byte) is very likely to be 0. And if it isn't, you're looking
at a character string highly unlikely to make sense on the console.

This brings in a wider issue. I did 'nm' on my kernel and, hey, there is
already an implementation of iconv linked in. It comes from sys/netsmb.
It's completely stubbed out--nothing but no-ops.  (Which raises the
question, if SMB needed iconv, is it working ok with iconv-that-does-
nothing? Christos corrected a reversed-memcpy-args typo in it that had
been there over 3 years, so maybe smb itself isn't being used that
heavily.)

The iconv originally came from fb and has some signs of great ambition
(conversions as LKMs, conversions specifiable by sysctl on the fly...).
All very cool and all very unimplemented.

I think there should be, for starters, a much less ambitious--but a
working--iconv in the kernel, moved out of netsmb and into prime time,
with an iconv.9 page. Loadable conversions and all that goo are all
very well for later. Here's what I think would make an initial version:

1. The iconv should work, internally, by using a pivot encoding--Unicode
   comes to mind--so that individual converters can be defined independently
   of each other and selectively linked into the kernel, and we don't get
   into the n*m mess of conversion-pairs. Nobody ever has to see this
   pivot encoding outside of iconv.c itself.

2. In config.5 you should be able to specify the native character encoding
   of your console device. That converter gets statically linked in.

3. Other converters can live in the source tree with appropriate attributes
   in conf/files. So, if you build an ACPI kernel, and we know the ACPI spec
   makes us deal sometimes with utf16 data, the acpi stuff has the
   utf16 attribute and that converter gets linked in. Now it is trivial
   to use iconv to convert the _STR result to the character encoding of the
   console, because both converters are present.

4. An initial set of converters to implement should be ascii, iso-8859_1,
   and utf-16. These all have the benefit that, if the internal pivot
   encoding is Unicode, they are all one-liners.

I think it is going to get more common that we run into specs like ACPI
or SMB that provide for data in specific character encodings that we will
have to deal with in the kernel, and we should have a single good story
for how we do it.

-- One more suggestion goes on the would-be-cool list:

5. Some extension to kprintf for printing a string that's in some known
   encoding. %ls is no good because getting to a wcharstring is itself
   a transcoding, so you just add an indirection without simplifying the
   problem. A more useful extension would be a way to just specify what
   encoding your string is in, and kprintf uses iconv to get from that to
   the console encoding. With extended-printf syntax a la ksh, it could
   look like:

   aprint_normal("[%(utf-16)s] ", str);

Comments?

-Chap