Announcement

Collapse
No announcement yet.

Linus Ends Up Accepting The DRM Changes For Linux 4.11

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

  • #21
    Originally posted by Almindor View Post
    This is clearly an issue of the person who allowed this code to bubble up all the way to Linus. We're not talking about a 3 man project here, if code gets all the way up there it needs to be at least build tested.

    As others have said, if I was Linus I'd probably deny it as well and have a little chat with whoever is the next in line down there.
    Linus is the only one implying that it wasn't build tested... and it just so happens that whatever options linus built with are incompatible with the changes... as the other developers have said Kconfig is inscrutable especially for new developers.

    Comment


    • #22
      Originally posted by cb88 View Post

      Linus is the only one implying that it wasn't build tested... and it just so happens that whatever options linus built with are incompatible with the changes... as the other developers have said Kconfig is inscrutable especially for new developers.
      Right. It seems like people are misunderstanding things a bit here, probably because they read the headline and spout off rather than actually looking into what happened.

      The code in question compiled just fine under certain options. It's only a different set, that Linux happened to have set for himself, that it failed.

      Apparently there is some automated build testing that goes through and tests all the possible combinations, but it can take days up to a couple weeks to finish running and this code was all committed within the last couple of days so it didn't get caught by that process.

      Of course, Linus's argument stands - they probably shouldn't merge stuff that was just committed so recently, exactly because of this issue. And you would hope that somewhere along the line the reviewers would have noticed these problems and the compiler warnings and had it fixed, which obviously didn't happen.

      Comment


      • #23
        Anyone who wants to improve their capabilities must be humble.

        Granted, we can't be push-overs or yes-men so it's important to have strong reactions at the proper time.

        The moral of the story - the right reaction at the right time.

        There's a time to be calm, and a time to freak out, a time to be humble and accept that we all have different skills and are each superior in at least one area. Likewise, everyone else is superior than each of us in at least one thing.

        If people were incapable of having strong reactions the world would be overun with murders, pedophiles, rapists, criminals, thiefs, liars, and so on...

        There's a time for Linus to get his guns smoking and time for tea time too.

        Comment


        • #24
          There's some merit in the idea though that Linus would have the heated discussions privately with the maintainers and mailing lists would remain technical mainly civil

          Comment


          • #25
            Indeed. Linus' reaction was fine, the way he expresses himself is not really fine. Well, it is fine for people who know how Linus works; they read the email realising that Linus overexaggerates everything, and that the real content of the message is "this code doesn't compile under certain conditions, why hasn't this been addressed before, please fix". However, for people who are new to this, it can get very confusing very fast. Quite a few people have been driven away from kernel development because of the lack of civility, and that's just sad.

            Comment


            • #26
              I think its time, the kernel and the device drivers is separated.

              Comment


              • #27
                My personal experience with kernel developers is that they are excellent people who are very helpful. I had a Microsoft SIdewinder force feedback 2 joystick which would lock the kernel under certain conditions. I emailed a kernel developer and he very promptly got back to me and I sent him the debug information and he resolved the problem. Took 2-3 hours and my joystick has worked fine on Linux with Force Feedback for the past 15 years.

                Comment


                • #28
                  Originally posted by swoorup View Post
                  I think its time, the kernel and the device drivers is separated.
                  So... a rewrite of Linux as a microkernel?

                  Comment


                  • #29
                    Anything, im load new snap suse Tumbleweed 20170224 with kernel 4.11 (for new laptop with gtx 1060) and i have unknown chipset 136000a1.

                    Comment


                    • #30
                      Originally posted by swoorup View Post
                      I think its time, the kernel and the device drivers is separated.
                      +1

                      Originally posted by LLStarks View Post

                      So... a rewrite of Linux as a microkernel?
                      imposing a stricter decoupling between the kernel core and drivers doesn't by any means imply a microkernel architecture ( although a microkernel architecture implies such decoupling - to a physical level in fact )
                      as a matter of fact most OS with monolithic / hybrid kernels (NT, Solaris, Os X, BSD, Minoca, AtheOS/Syllable, etc etc .. ) are also compartmentalized - in that data structures and methods are not "global" for everyone and his dog to mess with at whim, but accessed by an internal stable (or at least versioned) interface, allowing for newer drivers to be added to an existing system, or a system to be updated for security or efficiency just where it needed, without downloading the entire world

                      basically, Linux is the exception, rather than the norm..

                      and the reason for this is entirely political rather than technical - developers feared stable api's would encourage commercial vendors to produce closed source drivers , so it's a leverage
                      but they dont consider that :
                      a) a stable api is a development pratice, but sw licenses and practices are orthogonal - the gpl would be equally violated with a closed source driver developed against a "linux4" api, so it isn't more likely a vendor would do that;
                      b) a (versioned) stable api would not impede progress - yes, it would require some more forethought, but would reduce the amount of internal tinkering and rehashing ..
                      Last edited by silix; 28 February 2017, 09:14 AM.

                      Comment

                      Working...
                      X