Announcement

Collapse
No announcement yet.

Linus On GEM Patches: UNTESTED CRAP

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by SheeEttin View Post
    Is it just me, or is there a certain image of Linus being painted here?
    Pretty much, yeah.

    Comment


    • #22
      Driver developers could compile their own Kernel! Without any other outside patch and occasionally look into the logs.

      Comment


      • #23
        Originally posted by airlied View Post
        Do you think any kernel distro maintainers trawl the warnings in their build logs?

        You must live in a different world than everyone else.

        Dave.
        Hmm... When I write new code, I watch how it compiles, no matter how big the backdrop it's living in.

        Linus is right, people need to take more pride in their work and actually care about their results. Cavalier attitudes like that just give fodder to managers who believe that developers aren't important and are freely interchangeable.

        Comment


        • #24
          Originally posted by wswartzendruber View Post
          Pretty much, yeah.
          the image of a benevolent dicator who does not accept crap from his leutnants.

          Comment


          • #25
            If the compiler spits out tons of warnings when the kernel compiles it says one of two things:

            1) There is a problem with the compiler.
            2) There is a problem with the code.

            Therefore, for stuff intended to be put in mainline, warnings really ought to be looked into. Yes, it is a pain, and it slows things down, and perhaps some warnings involve a solution where the potential problem is recognized and dealt with, but it shouldn't get to the point where devs are just ignoring all the warnings. That kind of defeats the purpose of warnings, doesn't it?

            Comment


            • #26
              3) the code might be fishy in usual scenarios but in that special case the best/only possible solution.
              4) the compiler can not know everything the programmer knows.

              Comment


              • #27
                Here's what I got when compiling 2.6.27-git8:

                Code:
                 CC      drivers/gpu/drm/drm_auth.o
                  CC      drivers/gpu/drm/drm_bufs.o
                  CC      drivers/gpu/drm/drm_cache.o
                  CC      drivers/gpu/drm/drm_context.o
                  CC      drivers/gpu/drm/drm_dma.o
                  CC      drivers/gpu/drm/drm_drawable.o
                  CC      drivers/gpu/drm/drm_drv.o
                  CC      drivers/gpu/drm/drm_fops.o
                  CC      drivers/gpu/drm/drm_gem.o
                  CC      drivers/gpu/drm/drm_ioctl.o
                  CC      drivers/gpu/drm/drm_irq.o
                  CC      drivers/gpu/drm/drm_lock.o
                  CC      drivers/gpu/drm/drm_memory.o
                  CC      drivers/gpu/drm/drm_proc.o
                drivers/gpu/drm/drm_proc.c: In function 'drm_gem_one_name_info':
                drivers/gpu/drm/drm_proc.c:525: warning: format '%d' expects type 'int', but argument 3 has type 'size_t'
                drivers/gpu/drm/drm_proc.c:533: warning: format '%9d' expects type 'int', but argument 4 has type 'size_t'
                  CC      drivers/gpu/drm/drm_stub.o
                  CC      drivers/gpu/drm/drm_vm.o
                  CC      drivers/gpu/drm/drm_agpsupport.o
                  CC      drivers/gpu/drm/drm_scatter.o
                  CC      drivers/gpu/drm/ati_pcigart.o
                  CC      drivers/gpu/drm/drm_pci.o
                  CC      drivers/gpu/drm/drm_sysfs.o
                  CC      drivers/gpu/drm/drm_hashtab.o
                  CC      drivers/gpu/drm/drm_sman.o
                  CC      drivers/gpu/drm/drm_mm.o
                  CC      drivers/gpu/drm/drm_ioc32.o
                  LD      drivers/gpu/drm/drm.o
                  CC      drivers/gpu/drm/i915/i915_drv.o
                  CC      drivers/gpu/drm/i915/i915_dma.o
                  CC      drivers/gpu/drm/i915/i915_irq.o
                  CC      drivers/gpu/drm/i915/i915_mem.o
                  CC      drivers/gpu/drm/i915/i915_opregion.o
                  CC      drivers/gpu/drm/i915/i915_suspend.o
                  CC      drivers/gpu/drm/i915/i915_gem.o
                drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_gtt_pwrite':
                drivers/gpu/drm/i915/i915_gem.c:184: warning: unused variable 'vaddr_atomic'
                  CC      drivers/gpu/drm/i915/i915_gem_debug.o
                  CC      drivers/gpu/drm/i915/i915_gem_proc.o
                  CC      drivers/gpu/drm/i915/i915_gem_tiling.o
                  CC      drivers/gpu/drm/i915/i915_ioc32.o
                  LD      drivers/gpu/drm/i915/i915.o
                  LD      drivers/gpu/drm/i915/built-in.o
                  LD      drivers/gpu/drm/built-in.o
                  LD      drivers/gpu/built-in.o

                Comment


                • #28
                  Originally posted by airlied View Post
                  Do you think any kernel distro maintainers trawl the warnings in their build logs?

                  You must live in a different world than everyone else.

                  Dave.
                  Just to be clear, I didn't mean my post as a jab at you or Fedora/Red Hat, but rather that it bugs me that such a situation is generally considered normal. My inner Dijkstra pipes up at the oddest times, I guess...

                  Comment


                  • #29
                    Originally posted by highlandsun View Post
                    Hmm... When I write new code, I watch how it compiles, no matter how big the backdrop it's living in.

                    Linus is right, people need to take more pride in their work and actually care about their results. Cavalier attitudes like that just give fodder to managers who believe that developers aren't important and are freely interchangeable.
                    Do you then go and recompile the code on 32-bit/64-bit, powerpc/sparc etc..

                    The problem was warnings on a platform the code wasn't developed on.

                    Normally linux-next picks up this but it was on a holiday during this development cycle.

                    Dave.

                    Comment


                    • #30
                      Originally posted by airlied View Post
                      Do you then go and recompile the code on 32-bit/64-bit, powerpc/sparc etc..
                      If my code is meant to be cross architecture you better believe I do.

                      Comment

                      Working...
                      X