[PATCH 17/18] fs: Fix copyright symbol in printk()

[Brian Norris]

On Mon, Apr 22, 2013 at 9:44 PM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
> On Tue, 23 Apr 2013, Marek Vasut wrote:
>>>> printk() as the later produces the following output on dmesg
>>>>
>>>> instead of the expected one:
>>>>   jffs2: version 2.2. (NAND) \xffffffc2\xffffffa9 2001-2006 Red Hat,
>>>> Inc.
>>>>
>>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>>> Cc: David Woodhouse <dwmw2 at infradead.org>
>>>
>>>
>>> You appear to have discovered a problem with printk. Let's *fix* it
>>> rather than regressing to the 20th century to work around it though?
>>
>>
>> Should printk() even be capable of printing UTF8 stuff like that? How
>> should I
>> go about this?
>
>
> A lot of debugging in embedded systems happens over serial lines. While it
> might be nice to be able to print symbols like the copyright, I would think
> it has little value compared to the practicality of being able to connect
> whatever serial terminal or terminal emulator is available without getting
> odd character sequences.

FWIW, I debug my embedded systems over serial lines and these messages
currently render just fine (during initial boot-time print and via
dmesg). But not all environments are created equal I suppose.

I'm curious though, shouldn't such display be determined primarily by
the host-side environment where the console is being viewed? That is,
even for embedded development, going to be a fully-fledged system that
can be expected to handle modern text encodings, right? I'm honestly
not very knowledgeable in this area, so there could be many pitfalls
I'm missing. And I'm not even sure right now what would cause Marek's
system to print out that escape-char junk while printing fine on mine.

> What I'm trying to say is that it's not just printk that's at fault, it's
> worth considering the environment which printk is used in.

But this is not necessarily an argument against supporting it. Can
legacy support and UTF-8 coexist peacefully?

Brian