Announcement

Collapse
No announcement yet.

Linux 4.9 Kernel Tacks On Over 200k Lines Of Code

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

  • Linux 4.9 Kernel Tacks On Over 200k Lines Of Code

    Phoronix: Linux 4.9 Kernel Tacks On Over 200k Lines Of Code

    With all the new features in Linux 4.9, obviously Tux put on a bit of weight this kernel cycle... Here's some numbers...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's rather interesting to see "lines of code by languages" in terms of deletions/insertions. E.g.: how much Assembly was finally rewritten to C? Such kind of things.

    Comment


    • #3
      So the "nexus 5 support" - how extensive is it? Can we now flash a 4.9 mainline kernel on our Android phones?

      Comment


      • #4
        Isn't it time for Linux to switch to a micro-kernel model, where driver code gets developed completely independently from the kernel itself? Yesterday we had this posting about all those 'exciting' new features and it was all new drivers...

        Comment


        • #5
          Originally posted by hansg View Post
          Isn't it time for Linux to switch to a micro-kernel model, where driver code gets developed completely independently from the kernel itself? Yesterday we had this posting about all those 'exciting' new features and it was all new drivers...
          That would essentially mean a full rewrite.

          Feel free to argue that should happen, but don't expect it to gain much support among devs.

          Comment


          • #6
            there is always mkLinux

            Comment


            • #7
              Originally posted by hansg View Post
              Isn't it time for Linux to switch to a micro-kernel model, where driver code gets developed completely independently from the kernel itself? Yesterday we had this posting about all those 'exciting' new features and it was all new drivers...
              You are not the only one thinking about this. Several other have pondered this. Here is a Linux kernel developer suggesting something similar
              Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


              "It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you are prone to regressions. This problem can be solved by decoupling drivers from the kernel and supplying them separately so that you could enjoy stable kernel version X with brand new drivers like it's done in most other proprietary OS'es. I've been thinking of asking Linus about this decoupling for years already but I'm hesitant 'cause I'm 99.99999% sure he will downright reject this proposal."

              Comment


              • #8
                Originally posted by UbuntuRulez View Post
                You are not the only one thinking about this. Several other have pondered this. Here is a Linux kernel developer suggesting something similar
                Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite


                "It's not a secret that there are two basic ways of running a Linux distribution on your hardware. Either you use a stable distro which has quite an outdated kernel release which might not support your hardware or you run the most recent stable version but you lose stability and you are prone to regressions. This problem can be solved by decoupling drivers from the kernel and supplying them separately so that you could enjoy stable kernel version X with brand new drivers like it's done in most other proprietary OS'es. I've been thinking of asking Linus about this decoupling for years already but I'm hesitant 'cause I'm 99.99999% sure he will downright reject this proposal."
                Separating drivers from kernel could make the Android kernel fragmentation a joke in comparison too. Being forced to merge drivers makes things more contained in the same codebase and that might be good to not need to find a zillion sources to get drivers. And updating the kernel is good, it's a shame Linux distributions are so extremelly idiotic about being so slow about important parts of the OS like that (and MESA, web browsers that have vulnerability issues too often, etc).

                Comment


                • #9
                  Some people don't like blobs. They love the lack of a stable ABI, don't they?

                  It seems this is less of a problem for non-hardware drivers; for example fuse (filesystem in userspace) and cuse (character device in userspace) are stable ABIs.

                  Comment


                  • #10
                    Originally posted by andreano View Post
                    Some people don't like blobs. They love the lack of a stable ABI, don't they?

                    It seems this is less of a problem for non-hardware drivers; for example fuse (filesystem in userspace) and cuse (character device in userspace) are stable ABIs.
                    The lack of a stable ABI is what enables Linux to constantly evolve by not being tied down to some old interface that turned out to not be up to the task. The drawback of course is that out of kernel drivers have a much harder time.

                    Oh and btw micro-kernel and having drivers developed out of the kernel is not the same thing.

                    Comment

                    Working...
                    X