Announcement

Collapse
No announcement yet.

A Look At The New Features Of The Linux 4.4 Kernel

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

  • A Look At The New Features Of The Linux 4.4 Kernel

    Phoronix: A Look At The New Features Of The Linux 4.4 Kernel

    If all goes according to plan, the Linux 4.4 kernel merge window will end today with the release of the 4.4-rc1 kernel. As all of the major subsystem updates have already landed for Linux 4.4, here's my usual look at the highlights for this kernel cycle.

    http://www.phoronix.com/vr.php?view=22405

  • #2
    The link in the article for x86 Assembly code continues to be rewritten in C does not work.

    Comment


    • #3
      I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.

      Thus, I don't really get the point of limiting driver releases with kernel releases. The same way I don't get the point of limiting graphics driver releases with the version of Mesa. Mesa is/was just an OpenGL library. The drivers use the library, not the other way around... so why does the library get to have all the power?

      In this regard, Windows is way ahead of Linux. I shouldn't have to upgrade to a new kernel just to fix that pesky audio/networking/etc bug in my driver, wait for somebody to backport it to my kernel, or build the kernel myself. I should just be able to upgrade the driver.

      Comment


      • #4
        @Daktyl198
        Good points. How Linux handles distribution of drivers is one of many issues Linux has.

        Two big issues holding Linux back are handling platform support due to many smaller but compounding issues including legacy x86 code (ARM device tree is a shitty approach the damn thing is growing in size with every new board/SoC/configuration, disaster in the making) and
        software distribution/installation ( walled gardens of distro specific app packaging formats and
        incompatible package managers )

        Not to mention the problems with OpenGL header file and drivers on which you comment touches upon.
        This is a symptom of a bigger problem in Linux. Namely not having a good way to request, offer an API. Relying on header files is not a good solution. There should be a system not relying on headers.
        How are things done on Windows? Due to OpenGL being available but Microsoft doesn't like to support OpenGL there seems to be a way to support API's without much if any specific OS vendor support.
        Maybe avoiding name colisions could be done like how file formats are done but for API's and handles programs/drivers/devices. Drivers should have a way to specify which API, standard(s) they support by name and some metadata. Good identifiers, candidates for metadata wouldbe what organization makes the API and what is the official name of the API under standard organizations such as ISO/ECMA/others (<- extra information is used to avoid name collision, not many organizations would bring out two different API's under the exact same name).
        https://en.wikipedia.org/wiki/Standards_organization
        https://en.wikipedia.org/wiki/List_o..._organisations
        Of course a solution that doesn't require extra OS vendor code/cooperation would be superior and more desirable.

        The aforementioned issues are not an exhaustive list.
        Among many other issues, here is an example of one issue to be solved in Linux:
        https://en.wikipedia.org/wiki/Richacls
        Allowing for better access control lists. And operable without data loss / losing more advanced features with Windows ACLs

        Windows really is light-years ahead in some aspects of computing.

        To be fair to Linux. Packaging drivers with the kernel might have to do with the driver API's changing a lot. Making things difficult for non included drivers to be fixed. The shifting landscape not being conductive to having working drivers stay working for long outside the kernel tree/upstream.

        But despite all these issues don't despair people, Linux is getting better.
        Check out these two horrors from the past:

        There used to be a manually specified boot order for programs on starting up your Linux system.
        Basically package maintainers had to organize with every other relevant package maintainer and prepare a boot order manually!
        https://wiki.debian.org/LSBInitScrip...dencyBasedBoot
        Not to mention the mega driver nonsense that propped up a long time ago
        (linked article written on 30 September 2013):
        http://www.phoronix.com/scan.php?pag...tem&px=MTQ3Mzc
        Eric proposed Mesa Drivers For Mesa at the beginning of August as a way to (slightly) boost performance by bundling all of the Mesa/Gallium3D drivers into a single .so shared library so that link-time optimizations could be applied to them as a whole by the compiler. Additionally, this method can save disk space and has some other benefits too.
        Last edited by plonoma; 11-15-2015, 08:04 PM.

        Comment


        • #5
          Originally posted by Daktyl198 View Post
          I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.
          Well actually a lot of things can be built as modules, most distributions will even have the file systems, raid etc. code as modules. However it's impractical to switch out the module while the system is running - you can't rmmod a driver that is in use, so upgrading modules aside from the kernel, while possible, will still require a reboot anyways.

          Comment


          • #6
            Originally posted by nils_ View Post

            Well actually a lot of things can be built as modules, most distributions will even have the file systems, raid etc. code as modules. However it's impractical to switch out the module while the system is running - you can't rmmod a driver that is in use, so upgrading modules aside from the kernel, while possible, will still require a reboot anyways.
            ... So? Who cares about a reboot. I'm talking about software releases. I shouldn't have to wait for a new kernel to fix a simple bug in an audio/network/etc driver that was patched just after the current stable kernel dropped.

            And no, I'm not going to compile my own. I don't use Linux to spend 10 minutes compiling a kernel every time I want a bug fixed in a semi-timely manner... and without possibly breaking OTHER drivers. Most of us has run into the "my X hardware doesn't work without Y kernel, but Y kernel breaks my Z hardware!" issue and it's fucking ridiculous.

            Comment


            • #7
              Originally posted by Daktyl198 View Post
              I've never seen the point of considering drivers as "part of the Linux kernel". They're modules that get compiled in, yeah, but they're not really connected to the internal workings of the kernel, they're just interfaces with the hardware.
              garbage in - garbage out
              https://github.com/torvalds/linux/bl...i_nonsense.txt

              Comment


              • #8
                Originally posted by Daktyl198 View Post
                I shouldn't have to wait for a new kernel to fix a simple bug in an audio/network/etc driver that was patched just after the current stable kernel dropped.
                don't wait then, install git current

                Comment


                • #9
                  Originally posted by plonoma View Post
                  Windows really is light-years ahead in some aspects of computing.
                  And, conversely, also aeons behind in other areas. Security, performance (just switching from Windows to Linux saw everything I do with this PC perform better, including but not limited to, ironically, Windows native applications (either .NET apps, using Mono or just true native and run via Wine). I'll grant you though that the Linux field is hopelessly divided. Everyone and their dog is able (and sometimes it actually feels like actively engaging in) to release their own distro.

                  Personally, I have no idea how to fix Linux though. In reality, I suspect it will remain as divided. Heck, look at systemd, it has people once again either following it with a passion or avoiding it like the plague. Even less coherence in the Linux world now.

                  Comment


                  • #10
                    Originally posted by pal666 View Post
                    Right, the good old kernelspace drivers vs userspace drivers split. I guess the moral of the story is don't keep more of your driver stack in kernelspace than necessary and have it be GPL. Write stable interfaces to write userspace drivers against. Graphics drivers just happen to be annoying in the sense that necessary actually means quite a lot

                    Comment

                    Working...
                    X