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
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
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
> >>> 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
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
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
> 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
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
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
>
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
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 handle it
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
the
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
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 just
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 again
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 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 interface v0.102
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 have printk's
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 present loudly
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
./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 to
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 that contains
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 the console
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
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:
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:
> 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. Ã
> ^
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
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
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
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/.
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
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
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 codes.
I'm
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 chmod +x
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 tests in
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/. Generally
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 , but
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 response to
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 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 into the
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 something else in
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 [EMAIL PROTECTED]);
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 7bit ASCII
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:
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. Ã
^ the cursor hangs
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:
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
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
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
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 would
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
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
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
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 volatile
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 listed in
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 also post the
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 output rather
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
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
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
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
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
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?
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
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
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
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
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? There are
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 listed in
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 the
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 use of
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
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 particular
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 itself,
84 matches
Mail list logo
