Announcement

Collapse
No announcement yet.

Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support

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

  • Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support

    Phoronix: Linux 5.7 Positioned To Retire ARM 32-bit KVM Virtualization Support

    The upcoming Linux 5.7 kernel is preparing to bid farewell to KVM virtualization support on 32-bit ARM architectures...

    http://www.phoronix.com/scan.php?pag...32-bit-ARM-KVM

  • #2
    In any recent times, the 32-bit ARM KVM support perhaps was only used by anyone tinkering with it on an aging ARM SBC but without any serious use-case for 32-bit ARM KVM.
    "Once upon a time" linux was all about tinkering with stuff ...
    Today it is all just business.

    Comment


    • #3
      Originally posted by Raka555 View Post

      "Once upon a time" linux was all about tinkering with stuff ...
      Today it is all just business.
      yeah really annoying, why not leave users of old ARM machines this features, e.g. for testing, Qemu emulators, ... IMHO an modern OS should also be more fine grained modular, e.g. micro kernel to have all those features outside of the main kernel anyway: https://www.youtube.com/watch?v=EmQEE3cDxEo

      Comment


      • #4
        Originally posted by Raka555 View Post

        "Once upon a time" linux was all about tinkering with stuff ...
        Today it is all just business.
        Any serious tinkerer worth their salt would just write their own kernel, compiler, and development environment. And fork systemd and Gnome to run on it so they could have homed and parental controls.

        Comment


        • #5
          Originally posted by Raka555 View Post

          "Once upon a time" linux was all about tinkering with stuff ...
          Today it is all just business.
          Originally posted by rene View Post

          yeah really annoying, why not leave users of old ARM machines this features, e.g. for testing, Qemu emulators, ... IMHO an modern OS should also be more fine grained modular, e.g. micro kernel to have all those features outside of the main kernel anyway: https://www.youtube.com/watch?v=EmQEE3cDxEo
          I'd like to have the feature in there, too. I've got a ton of 32-bit ARM devices hanging around. Features are great. Some even have enough RAM to actually be able to run a small VM. Problem is, who's going to maintain KVM support for it? Maintaining virtualization isn't easy. Realistically speaking, very few people use the feature. I guess there's some consumer NAS devices that *could* use it, but those companies aren't stepping forward. Most would rather you buy the more expensive x86 hardware if you're going to attempt virtualization. Same with the RPi foundation. The first two RPi generations were 32-bit.

          Honestly, with those types of memory constraints, containers make more sense than VMs in the first place. Despite the feature being there, there's no consumer/prosumer VM images for ARM. Nobody's built the kind of images that would run and are useful. Most of it is for developers, and most who are developing on ARM either use the hardware they need, or they use qemu on a desktop.

          It's also worth mentioning that containers on ARM weren't that big until last April when ARM and Docker started a partnership to push multi-architecture builds. Until then you had to roll your own. Which in most cases just wasn't worth the effort for most people. And I think it's still being built for 64-bit hardware.

          It's a shame 32-bit ARM support didn't start getting good until people started wanting more out of their systems. But at least we caught the tail end of it thanks to corporate sponsors. And the good news is most affordable tinkerer devices for sale these days are 64-bit capable.

          Comment


          • #6
            Originally posted by Raka555 View Post
            "Once upon a time" linux was all about tinkering with stuff ...
            Today it is all just business.
            How is it "all just business" when developers want to remove a feature that is largely unused, and said feature is also impeding new development? I don't see how this is related to hobbyists vs. corporations, this is normal software engineering.

            Also, when did they decide to maintain unused features just for the sake of tinkering in the past?

            In the earlier days, the kernel developers were generally fine with breaking userspace and making radical internal changes, definitely not the conservative tinkerers you seem to imagine.

            Comment


            • #7
              Originally posted by andyprough View Post

              Any serious tinkerer worth their salt would just write their own kernel, compiler, and development environment. And fork systemd and Gnome to run on it so they could have homed and parental controls.
              I see what you did there ... and I like it.

              Comment


              • #8
                Originally posted by rene View Post
                yeah really annoying, why not leave users of old ARM machines this features,
                because it will most likely break because of some other change and if no maintainer wants to fix it then it's worse as it's "ok" on paper but broken in practice. Been there with Mesa and (very) old radeon GPUs, and for the Xorg module for SiS graphics, among other things.

                I'm sure you can also dig up some other examples on your own as you have an extensive collection of old hardware.

                Comment


                • #9
                  Originally posted by Raka555 View Post
                  "Once upon a time" linux was all about tinkering with stuff ...
                  Today it is all just business.
                  Just the way we like it.

                  Comment


                  • #10
                    Originally posted by Space Heater View Post

                    In the earlier days, the kernel developers were generally fine with breaking userspace and making radical internal changes, definitely not the conservative tinkerers you seem to imagine.
                    Internal changes are fine; the kernel has no fixed internal or driver ABI. Userspace breakage is verboten, and would never be taken lightly by Linus who has final say. If a userspace program no longer runs, generally this is not because of kernel changes, but library interface changes. E.g. I can still run a libc5 Mosaic binary on my modern system, but I have to round up a bunch of ancient libraries, and it has problems because userspace completely re-organized how it did many things over 20 years ago. However if some subsystem is broken, abandoned, etc. it may be dropped going forward. The source is always still there, if anyone wants to pick it up and fix it. All it really takes is one person to speak up and do the work...

                    Comment

                    Working...
                    X