All of lore.kernel.org
 help / color / mirror / Atom feed
* Arm Compiler - Part 1 of Compiling Tests
@ 2014-07-07  5:22 Nick Krause
  2014-07-07 13:46 ` Theodore Ts'o
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Krause @ 2014-07-07  5:22 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]

Here are my logs of the builds attached  with warnings if they succeed
for now failing arm configs
according to the tests here,
http://kisskb.ellerman.id.au/kisskb/branch/9/. I didn't do
arm-randconfig
through
Cheers Nick
P.S. If it's hard to read please let me known :)

[-- Attachment #2: Logs --]
[-- Type: application/octet-stream, Size: 4883 bytes --]

Logs

iop13xx_defconfig: Succeeds with warnings
Build Warnings  for iop13xx
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;

mackerel_defconfig : Succeeds with warnings
Build Warnings for markerel_defconfig
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;

marzen_defconfig : Succeeds the build 
Build warnings for marzen_defconfig
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
          ^

nuc910_defconfig: Succeeds the build 

Build warnings for nuc910_defconfig  
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
          ^
nuc950_defconfig: Succeeds the build
Build Warnings for nuc950_defconfig
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
          ^
nuc960_defconfig: Succeeds the Build 
Build Warnings for nuc960_defconfig
arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
          ^
 
s5p64x0_defconfig: Build Succeeds 

arch/arm/kernel/return_address.c:63:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
 #warning "TODO: return_address should use unwind tables"
  ^
fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:16: note: ‘to’ was declared here
   size_t from, to;
                ^
fs/direct-io.c:1011:12: warning: ‘from’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;
            ^
fs/direct-io.c:913:10: note: ‘from’ was declared here
   size_t from, to;
          ^
End of logs 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Arm Compiler - Part 1 of Compiling Tests
  2014-07-07  5:22 Arm Compiler - Part 1 of Compiling Tests Nick Krause
@ 2014-07-07 13:46 ` Theodore Ts'o
  2014-07-07 17:35   ` Nick Krause
  0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2014-07-07 13:46 UTC (permalink / raw)
  To: Nick Krause; +Cc: linux-kernel

On Mon, Jul 07, 2014 at 01:22:13AM -0400, Nick Krause wrote:
> Here are my logs of the builds attached  with warnings if they succeed
> for now failing arm configs
> according to the tests here,

fs/direct-io.c: In function ‘__blockdev_direct_IO’:
fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
    u = (to - from) >> blkbits;

OK, do you see why this is a false positive?  And why asking the
thousands of people "in the commmunity" to all do exactly the same
evaluation is a massive waste of time?

And why people, after doing a quick evaluation to determine that the
very first warning you sent out (which was repeated multiple times in
your log; you didn't even bother to winnow out duplicate warnings)
is a false positive, might be inclined to ignore all e-mails from
you "asking for help" in the future?

Look, it's good that you're being enthusiastic.  But you need to do
more than just send screen shots of a kernel bugzilla where it's
already been explained to you that darned few people care about the
open/closed statistics, or running builds to complain about warnings.

If you want to send a patch to clean up the warning, figure out how to
do that, and then to send the to the right people.  (Hint: reading the
Documentation/SubmittingPatches and Documentation/Submitchecklist
files.)

Regards,

						- Ted

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Arm Compiler - Part 1 of Compiling Tests
  2014-07-07 13:46 ` Theodore Ts'o
@ 2014-07-07 17:35   ` Nick Krause
  2014-07-07 18:22     ` Paul Bolle
  2014-07-08 14:37     ` Jason Cooper
  0 siblings, 2 replies; 6+ messages in thread
From: Nick Krause @ 2014-07-07 17:35 UTC (permalink / raw)
  To: Theodore Ts'o, Nick Krause, linux-kernel

That's fine I don't mind cleaning up the warning  or not using Bugzilla.
On the other hand there seems to be too many FIXMEs in the main
kernel for one person to fix. In addition all the arm configs that were
failing for linux next to compile that didn't succeed are succeeded as
of now. That seems useful to tell the arm developers.
Cheers Nick


On Mon, Jul 7, 2014 at 9:46 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> On Mon, Jul 07, 2014 at 01:22:13AM -0400, Nick Krause wrote:
>> Here are my logs of the builds attached  with warnings if they succeed
>> for now failing arm configs
>> according to the tests here,
>
> fs/direct-io.c: In function ‘__blockdev_direct_IO’:
> fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>     u = (to - from) >> blkbits;
>
> OK, do you see why this is a false positive?  And why asking the
> thousands of people "in the commmunity" to all do exactly the same
> evaluation is a massive waste of time?
>
> And why people, after doing a quick evaluation to determine that the
> very first warning you sent out (which was repeated multiple times in
> your log; you didn't even bother to winnow out duplicate warnings)
> is a false positive, might be inclined to ignore all e-mails from
> you "asking for help" in the future?
>
> Look, it's good that you're being enthusiastic.  But you need to do
> more than just send screen shots of a kernel bugzilla where it's
> already been explained to you that darned few people care about the
> open/closed statistics, or running builds to complain about warnings.
>
> If you want to send a patch to clean up the warning, figure out how to
> do that, and then to send the to the right people.  (Hint: reading the
> Documentation/SubmittingPatches and Documentation/Submitchecklist
> files.)
>
> Regards,
>
>                                                 - Ted

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Arm Compiler - Part 1 of Compiling Tests
  2014-07-07 17:35   ` Nick Krause
@ 2014-07-07 18:22     ` Paul Bolle
  2014-07-07 20:10       ` Nick Krause
  2014-07-08 14:37     ` Jason Cooper
  1 sibling, 1 reply; 6+ messages in thread
From: Paul Bolle @ 2014-07-07 18:22 UTC (permalink / raw)
  To: Nick Krause; +Cc: Theodore Ts'o, linux-kernel

On Mon, 2014-07-07 at 13:35 -0400, Nick Krause wrote:
> On the other hand there seems to be too many FIXMEs in the main
> kernel for one person to fix.

A quick grep for FIXMEs (also including the "XXX" pattern, which
basically means the same thing) triggers over 7000 hits. Even with a
(rather optimistic) one hour per FIXME that's over three years of work
(assuming a sane working hours/year metric).

Moreover, you appear to misunderstand the meaning of these FIXMEs. It's
not a marker for something trivial that somehow never got done. It might
actually mean all kind of things. In many cases it points at a hard, or
time consuming, etc., problem that no one has yet found a way, or the
time, to fix properly.

I would not advise someone new to the kernel to grep for FIXMEs to see
if they could contribute something. There are many things those people
could do, but those FIXMEs seem an awkward place to start.


Paul Bolle


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Arm Compiler - Part 1 of Compiling Tests
  2014-07-07 18:22     ` Paul Bolle
@ 2014-07-07 20:10       ` Nick Krause
  0 siblings, 0 replies; 6+ messages in thread
From: Nick Krause @ 2014-07-07 20:10 UTC (permalink / raw)
  To: Paul Bolle; +Cc: Theodore Ts'o, linux-kernel

I do known what they mean. It's good work for a long time
that isn't getting worked on therefore it seems good for
me to work on.
Cheers Nick

On Mon, Jul 7, 2014 at 2:22 PM, Paul Bolle <pebolle@tiscali.nl> wrote:
> On Mon, 2014-07-07 at 13:35 -0400, Nick Krause wrote:
>> On the other hand there seems to be too many FIXMEs in the main
>> kernel for one person to fix.
>
> A quick grep for FIXMEs (also including the "XXX" pattern, which
> basically means the same thing) triggers over 7000 hits. Even with a
> (rather optimistic) one hour per FIXME that's over three years of work
> (assuming a sane working hours/year metric).
>
> Moreover, you appear to misunderstand the meaning of these FIXMEs. It's
> not a marker for something trivial that somehow never got done. It might
> actually mean all kind of things. In many cases it points at a hard, or
> time consuming, etc., problem that no one has yet found a way, or the
> time, to fix properly.
>
> I would not advise someone new to the kernel to grep for FIXMEs to see
> if they could contribute something. There are many things those people
> could do, but those FIXMEs seem an awkward place to start.
>
>
> Paul Bolle
>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Arm Compiler - Part 1 of Compiling Tests
  2014-07-07 17:35   ` Nick Krause
  2014-07-07 18:22     ` Paul Bolle
@ 2014-07-08 14:37     ` Jason Cooper
  1 sibling, 0 replies; 6+ messages in thread
From: Jason Cooper @ 2014-07-08 14:37 UTC (permalink / raw)
  To: Nick Krause; +Cc: Theodore Ts'o, linux-kernel

Nick,

Please don't top-post.  I've fixed it up ...

On Mon, Jul 07, 2014 at 01:35:24PM -0400, Nick Krause wrote:
> On Mon, Jul 7, 2014 at 9:46 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> > On Mon, Jul 07, 2014 at 01:22:13AM -0400, Nick Krause wrote:
> >> Here are my logs of the builds attached  with warnings if they succeed
> >> for now failing arm configs
> >> according to the tests here,
> >
> > fs/direct-io.c: In function ‘__blockdev_direct_IO’:
> > fs/direct-io.c:1011:12: warning: ‘to’ may be used uninitialized in this
> > function [-Wmaybe-uninitialized]
> >     u = (to - from) >> blkbits;
> >
> > OK, do you see why this is a false positive?  And why asking the
> > thousands of people "in the commmunity" to all do exactly the same
> > evaluation is a massive waste of time?

I already sent a patch explaining it was a false-positive and silencing
the warning:

  http://www.gossamer-threads.com/lists/linux/kernel/1956499

> In addition all the arm configs that were failing for linux next to
> compile that didn't succeed are succeeded as of now. That seems useful
> to tell the arm developers.

We already have a buildbot running and automated boot testing.  The
mailinglist is here:

  http://lists.linaro.org/mailman/listinfo/kernel-build-reports

Links to the reports are in the emails.  Please review and see if there
is anything we're missing.  Please keep in mind this is a volunteer task
for those currently running it.  Contributions would be much more
appreciated than good ideas ;-)

thx,

Jason.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2014-07-08 14:37 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-07  5:22 Arm Compiler - Part 1 of Compiling Tests Nick Krause
2014-07-07 13:46 ` Theodore Ts'o
2014-07-07 17:35   ` Nick Krause
2014-07-07 18:22     ` Paul Bolle
2014-07-07 20:10       ` Nick Krause
2014-07-08 14:37     ` Jason Cooper

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.