| Message ID | 1366665870-8998-1-git-send-email-marex@denx.de |
|---|---|
| State | New, archived |
| Headers | show |
Dear Marek Vasut, you're such a moron, leaving that 17/18 stuff in the subject ... at least be sorry for confusing others! :-/ > Use regular ASCII "(C)" string instead of UTF8 "©" string in > 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@denx.de> > Cc: David Woodhouse <dwmw2@infradead.org> ... yes, I'm sorry :-( > --- > fs/jffs2/super.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c > index 0defb1c..8916eb8 100644 > --- a/fs/jffs2/super.c > +++ b/fs/jffs2/super.c > @@ -381,7 +381,7 @@ static int __init init_jffs2_fs(void) > #ifdef CONFIG_JFFS2_SUMMARY > " (SUMMARY) " > #endif > - " © 2001-2006 Red Hat, Inc.\n"); > + " (C) 2001-2006 Red Hat, Inc.\n"); > > jffs2_inode_cachep = kmem_cache_create("jffs2_i", > sizeof(struct jffs2_inode_info), Best regards, Marek Vasut
On Mon, 2013-04-22 at 23:24 +0200, Marek Vasut wrote: > Use regular ASCII "(C)" string instead of UTF8 "©" string in > 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@denx.de> > Cc: David Woodhouse <dwmw2@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?
Dear David Woodhouse, > On Mon, 2013-04-22 at 23:24 +0200, Marek Vasut wrote: > > Use regular ASCII "(C)" string instead of UTF8 "©" string in > > 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@denx.de> > > Cc: David Woodhouse <dwmw2@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? Best regards, Marek Vasut
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@denx.de> >>> Cc: David Woodhouse <dwmw2@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. 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. /Ricard
On Mon, Apr 22, 2013 at 9:44 PM, Ricard Wanderlof <ricard.wanderlof@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@denx.de> >>>> Cc: David Woodhouse <dwmw2@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
diff --git a/fs/jffs2/super.c b/fs/jffs2/super.c index 0defb1c..8916eb8 100644 --- a/fs/jffs2/super.c +++ b/fs/jffs2/super.c @@ -381,7 +381,7 @@ static int __init init_jffs2_fs(void) #ifdef CONFIG_JFFS2_SUMMARY " (SUMMARY) " #endif - " © 2001-2006 Red Hat, Inc.\n"); + " (C) 2001-2006 Red Hat, Inc.\n"); jffs2_inode_cachep = kmem_cache_create("jffs2_i", sizeof(struct jffs2_inode_info),
Use regular ASCII "(C)" string instead of UTF8 "©" string in 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@denx.de> Cc: David Woodhouse <dwmw2@infradead.org> --- fs/jffs2/super.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)