• boredsquirrel@slrpnk.net
    link
    fedilink
    arrow-up
    3
    arrow-down
    2
    ·
    2 months ago

    Monolithic kernels and drivers are an issue.

    I understand why its easy, but on Fedora Atomic I even have all the userspace drivers for intel, amd, nvidia and maybe more, even though I clearly just use intel…

    • xan1242@lemmy.dbzer0.com
      link
      fedilink
      arrow-up
      5
      arrow-down
      1
      ·
      2 months ago

      This is the real issue. This is one area that Windows, despite its historical hardships, handles much better.

      (Mac OS too but they killed kexts for the public anyway)

      I’d love to see a more dynamic approach (that doesn’t rely on DKMS) someday.

      • Chewy@discuss.tchncs.de
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        I believe the advantage is that old drivers still work as they are all in the kernel. With them sharing much code it’s not even that big of a disk space issue.

        In a way it’s great that I’m able to replace any part of my system and it just works without me having to make sure the old GPU driver doesn’t leave some traces behind–altough while writing this the latter part shouldn’t be an issue with Windows auto download and installation of drivers.

    • Coelacanthus@lemmy.kde.social
      link
      fedilink
      arrow-up
      3
      ·
      2 months ago

      The problem is not caused by mono kernel. Just because AMDGPU driver was developed in mono style. i.e. they include the code of all generations in one driver. In monolithic kernel, the developer can develop drivers with “micro” style. e.g. Intel’s GPU driver doesn’t use mono style, they created a new driver when they changed GPU hardware architecture.

      Monolithic kernel is a concept about address space. If all parts of a kernel are running in the same address space, this is a monolithic kernel, otherwise it’s a micro kernel.

      This problem is about how to split parts, but not how to place parts in memory.