On Jun 8 2007 18:39, Adrian Bunk wrote:
>> > >>> Does the console handle it correctly during boot?
>>
>> Yes
That's most likely because printk() handles neither special chars nor
special fun (like ANSI color and movement codes). Hence, we should be
safe should there be spurious utf8 output on th
On Fri, Jun 08, 2007 at 04:42:36PM +0100, Alan Cox wrote:
> > >>> Does the console handle it correctly during boot?
>
> Yes
>
> > >>> Can all tools that process the syslog cope with it?
>
> Thats a stupid question. The tools people normally use can just fine.
>
> > >If you find any source file
> ./drivers/infiniband/core/multicast.c:UTF-8 Unicode C
> program text
> ./drivers/infiniband/core/sa.h: UTF-8 Unicode C
> program text
> ./drivers/infiniband/core/sa_query.c: UTF-8 Unicode C
> program text
These three seem
On Fri, 2007-06-08 at 17:16 +0200, Jan Engelhardt wrote:
> So, we had some ISO8859-1 and some UTF-8 in there already. (And as for
> MODULE_AUTHOR, it should stay there - 'fix' modinfo instead.)
Ok.
Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
> >>> Does the console handle it correctly during boot?
Yes
> >>> Can all tools that process the syslog cope with it?
Thats a stupid question. The tools people normally use can just fine.
> >If you find any source file that contains UTF-8 outside of comments
> >please complain loudly.
>
> I p
On Jun 8 2007 16:42, Adrian Bunk wrote:
>On Fri, Jun 08, 2007 at 04:34:01PM +0200, Jesper Juhl wrote:
>> On 08/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
>> [snip]
>>>
>>> It's not only about MODULE_AUTHOR, if you consider it rude to limit
>>> people's names to ASCII, then don't forget that we
On Fri, Jun 08, 2007 at 04:34:01PM +0200, Jesper Juhl wrote:
> On 08/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> [snip]
>>
>> It's not only about MODULE_AUTHOR, if you consider it rude to limit
>> people's names to ASCII, then don't forget that we have printk's like
>> Linux agpgart interfa
On 08/06/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
[snip]
It's not only about MODULE_AUTHOR, if you consider it rude to limit
people's names to ASCII, then don't forget that we have printk's like
Linux agpgart interface v0.102 (c) Dave Jones
What happens if the maintainer changes and it's
On Fri, Jun 08, 2007 at 11:52:19AM +0100, Alan Cox wrote:
> > The problem is that the second byte is interpreted as a control code.
> >
> > Is there any trick to get the shell working again in this situation?
> > The cursor hangs, and I've not yet found a trick to do anything in this
> > xterm aga
> The problem is that the second byte is interpreted as a control code.
>
> Is there any trick to get the shell working again in this situation?
> The cursor hangs, and I've not yet found a trick to do anything in this
> xterm again (except for killing it from another xterm).
For gnome terminal j
On 06/08/2007 11:31 AM, Andy Whitcroft wrote:
Ok, the latest version 0.04 is released and I have also put up the
complete script at:
http://www.shadowen.org/~apw/public/checkpatch/checkpatch.pl-0.04
Previous versions are also there.
Thank you. False positive:
do not use assignment
Rene Herman wrote:
> On 06/04/2007 09:08 PM, Andy Whitcroft wrote:
>
>> I guess line length and white space checks make sense some degree on
>> those files. I'll sort that out and I guess we'll have anohter version.
>
> Could you then also post the thing itself, and not just a patch against
> th
On Fri, 2007-06-08 02:04:55 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 08, 2007 at 12:41:17AM +0100, Alan Cox wrote:
> > (And incidentially since the Linux fs has been defined to be utf-8 for
> > naming for many years you'll find the same problem using "ls")
>
> No, "ls" can handl
On Fri, 2007-06-08 at 02:04 +0200, Adrian Bunk wrote:
> The difference is that "ls" expects and handles such issues while
> "lsmod" (and most likely also other userspace working with kernel
> output) does not yet handle it resulting in problems if bytes are
> wrongly interpreted as control code
On Fri, Jun 08, 2007 at 12:41:17AM +0100, Alan Cox wrote:
> > I added a MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>") into the "raw"
> > module:
> >
> > # echo $LANG
> > C
> > # modinfo --version
> > module-init-tools version 3.3-pre11
> > # modinfo raw
> > filename: /lib/modules/2.6.21.2/
On Fri, Jun 08, 2007 at 01:21:52AM +0200, Adrian Bunk wrote:
>...
> I added a MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>") into the "raw"
> module:
>
> # echo $LANG
> C
> # modinfo --version
> module-init-tools version 3.3-pre11
> # modinfo raw
> filename: /lib/modules/2.6.21.2/kernel/dri
> I added a MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>") into the "raw"
> module:
>
> # echo $LANG
> C
> # modinfo --version
> module-init-tools version 3.3-pre11
> # modinfo raw
> filename: /lib/modules/2.6.21.2/kernel/drivers/char/raw.ko
> author: J. Ã
> ^ th
On Thu, Jun 07, 2007 at 11:22:48PM +0100, Alan Cox wrote:
> On Thu, 7 Jun 2007 21:34:13 +0200
> Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Jun 07, 2007 at 04:28:20PM +0200, Jan Engelhardt wrote:
> > >
> > > On Jun 6 2007 11:05, Jesper Juhl wrote:
> > > >
> > > > - Source files should be
On Thu, 7 Jun 2007 21:34:13 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Thu, Jun 07, 2007 at 04:28:20PM +0200, Jan Engelhardt wrote:
> >
> > On Jun 6 2007 11:05, Jesper Juhl wrote:
> > >
> > > - Source files should be 7bit ASCII
> >
> > Nah. Think of
> >
> > MODULE_AUTHOR("J. Ørsted <
On Thu, 7 Jun 2007 21:32:29 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 06, 2007 at 11:05:07AM +0200, Jesper Juhl wrote:
> >...
> > - Source files should be 7bit ASCII and Documentation/Kbuild
> > files/etc should be UTF-8, test that the patch honors that and doesn't
> > put somethi
On Thu, Jun 07, 2007 at 04:28:20PM +0200, Jan Engelhardt wrote:
>
> On Jun 6 2007 11:05, Jesper Juhl wrote:
> >
> > - Source files should be 7bit ASCII
>
> Nah. Think of
>
> MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>");
>...
NO!
Code must be 7bit ASCII.
This includes everything that gets
On Wed, Jun 06, 2007 at 11:05:07AM +0200, Jesper Juhl wrote:
>...
> - Source files should be 7bit ASCII and Documentation/Kbuild
> files/etc should be UTF-8, test that the patch honors that and doesn't
> put something else in (cleanups that remove 8bit ASCII etc from a
> source file is OK though).
On Jun 7 2007 12:46, Andy Whitcroft wrote:
>
>Jesper Juhl wrote:
>> On 04/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>>
>>> This version brings a host of changes to cure false positives and
>>> bugs detected on patches submitted to lkml and -mm. It also brings
>>> a number of new tests in
On 07/06/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
On Jun 6 2007 11:05, Jesper Juhl wrote:
>
> - Source files should be 7bit ASCII
Nah. Think of
MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>");
That's true. I wrote that comment shortly after reading
http://lkml.org/lkml/2007/6/4/448 ,
On Jun 6 2007 11:05, Jesper Juhl wrote:
>
> - Source files should be 7bit ASCII
Nah. Think of
MODULE_AUTHOR("J. Ørsted <[EMAIL PROTECTED]>");
> - Maybe warn about usage of float/double in source files?
Generally yes, maybe, but see arch/i386/kernel/cpu/bugs.c,
arch/i386/math-emu/. Generall
On 07/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
Jesper Juhl wrote:
> On 04/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>
>> This version brings a host of changes to cure false positives and
>> bugs detected on patches submitted to lkml and -mm. It also brings
>> a number of new test
Jesper Juhl wrote:
> On 04/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>>
>> This version brings a host of changes to cure false positives and
>> bugs detected on patches submitted to lkml and -mm. It also brings
>> a number of new tests in response to reviews, of particular note:
>>
> A chm
On 04/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
A chmod +x scripts/checkpatch.pl woul
On 04/06/07, Andy Whitcroft <[EMAIL PROTECTED]> wrote:
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
I have a few ideas for additional chec
jschopp wrote:
>> The original suggestion was to count them and only complain if there
>> were "lots". I had thought though that the general consensus was that
>> #ifdef in C files was pretty much frowned upon. I must admit to working
>> to the "you must be able to justify all winges in the outpu
Randy Dunlap wrote:
> On Mon, 04 Jun 2007 21:08:07 +0200 Rene Herman wrote:
>
>> On 06/04/2007 09:08 PM, Andy Whitcroft wrote:
>>
>>> I guess line length and white space checks make sense some degree on
>>> those files. I'll sort that out and I guess we'll have anohter version.
>> Could you then
jschopp wrote:
>> This version brings a host of changes to cure false positives and
>> bugs detected on patches submitted to lkml and -mm. It also brings
>> a number of new tests in response to reviews, of particular note:
>>
>> - catch use of volatile
>> - allow deprecated functions to be lis
On Mon, Jun 04, 2007 at 10:46:24AM +0100, Andy Whitcroft wrote:
>
> This version brings a host of changes to cure false positives and
> bugs detected on patches submitted to lkml and -mm. It also brings
> a number of new tests in response to reviews, of particular note:
>
> - catch use of vola
On Mon, 04 Jun 2007 21:08:07 +0200 Rene Herman wrote:
> On 06/04/2007 09:08 PM, Andy Whitcroft wrote:
>
> > I guess line length and white space checks make sense some degree on
> > those files. I'll sort that out and I guess we'll have anohter version.
>
> Could you then also post the thing its
On 06/04/2007 09:08 PM, Andy Whitcroft wrote:
I guess line length and white space checks make sense some degree on
those files. I'll sort that out and I guess we'll have anohter version.
Could you then also post the thing itself, and not just a patch against the
previous version for us chick
Andrew Morton wrote:
> On Mon, 04 Jun 2007 10:46:24 +0100
> Andy Whitcroft <[EMAIL PROTECTED]> wrote:
>
>> This version brings a host of changes to cure false positives and
>> bugs detected on patches submitted to lkml and -mm. It also brings
>> a number of new tests in response to reviews, of pa
On Mon, 04 Jun 2007 10:46:24 +0100
Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> This version brings a host of changes to cure false positives and
> bugs detected on patches submitted to lkml and -mm. It also brings
> a number of new tests in response to reviews, of particular note:
>
> - catch
The original suggestion was to count them and only complain if there
were "lots". I had thought though that the general consensus was that
#ifdef in C files was pretty much frowned upon. I must admit to working
to the "you must be able to justify all winges in the output" rather
than expecting t
jschopp wrote:
>> This version brings a host of changes to cure false positives and
>> bugs detected on patches submitted to lkml and -mm. It also brings
>> a number of new tests in response to reviews, of particular note:
>>
>> - catch use of volatile
>> - allow deprecated functions to be lis
On Jun 4 2007 10:46, Andy Whitcroft wrote:
>
> - catch use of volatile
Speaking of volatile, "register" is probably just as unwanted.
Then, "extern inline" is one thing to catch (does not happen
that often, but it does not cost too much either).
> - warn about #ifdef's in c files
Really? Ther
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
- allow deprecated functions to be listed in feature-removal-schedule
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
- allow deprecated functions to be listed in feature-removal-schedule
42 matches
Mail list logo
