Announcement

Collapse
No announcement yet.

"Very Disruptive" Change Hurts ARM Linux Support

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

  • #21
    My initial thought was the same as recent posts above, ie that the disclaimers were similar to X11 or BSD license text, but I suspect the key issue is use of the word "indemnification".

    IANAL but "indemnification" seems to imply something a lot stronger than the usual "it's not my fault, man" license text -- eg responsibility for covering the indemnified party's costs if something goes really wrong.

    Comment


    • #22
      http://lists.infradead.org/pipermail...il/162339.html

      Apparently Linus thinks this is just the FSF nitpicking.

      Comment


      • #23
        Originally posted by droidhacker View Post
        You're obviously stupid, because it is almost a given that it is NECESSARY to fork the GPL to ALLOW COMPATIBILITY with licenses that indemnify persons or organizations.
        You are obviously stupid, the problem here (if there is any) is that Linus chose to licence Linux under 'GPL v2 ONLY' rather than often used 'GPLv2 or later'. He did this because he thinks GPLv2 is a perfect licence as is, which is fine. I seriously doubt that Torvalds will change the licencing because of this library being licenced incompatible with GPLv2 which is the licence he again think is 'perfect'.

        Either way this has nothing to do with FSF, they can't tell Linus what licence to use or whether or not he allows 'or later'. He made this choice, he (and the other copyright holders of Linux) are the only ones who can change the licencing should they want to (very doubtful). Also FSF can't force the Linux devs to do anything in this regard should they think this is not a real licence issue.

        Originally posted by droidhacker View Post
        In fact, you may want to look up the reason why Torvalds REJECTED v3. I'll give you a hint: It has NOTHING to do with indemnification.
        The reason he objected to GPLv3 was about the anti-tivoization clause.

        Comment


        • #24
          Originally posted by XorEaxEax View Post
          He made this choice, he (and the other copyright holders of Linux) are the only ones who can change the licencing should they want to (very doubtful)..
          I can't imagine Linux license ever changing. According to Ohloh.net Linux has had contributions from almost 11000 developers. Getting approval from even a fraction of that would take ages... not to mentiont that most of the copyright is owned by companies (500+) and who knows what kind of deals they have made with each others. People have died, are unavailable, companies have went under and so on and so forth. So even if they wanted to change the license it would be almost impossible.

          Comment


          • #25
            Originally posted by Teho View Post
            I can't imagine Linux license ever changing.
            Me neither, I've seen no indication of Linus or any other core Linux devs have expressed any interest in re-licencing. Quite the opposite, every chance Linus gets he seems to highlight his choice of GPLv2 as a key aspect of Linux success.

            Of course this doesn't have to be an issue either way, if the kernel devs are fine with this licence then there's really nothing else to say. They set the rules for how to enforce the licencing as they are the copyright holders, gpl-violations which reported this licence incompability has no sway and neither does FSF, again it's up to the copyright holders (Linux devs).

            Beyond that, judging by the mailing-list exchange this floating point emulation is mostly being done in user-space these days and as such it seems likely this in-kernel library will be deprecated anyway, so very much a storm in a teacup. The real action in the mailing list was the angry spat between Russel King and Måns Rullgård, what was that about?

            Comment


            • #26
              Originally posted by XorEaxEax View Post
              Me neither, I've seen no indication of Linus or any other core Linux devs have expressed any interest in re-licencing. Quite the opposite, every chance Linus gets he seems to highlight his choice of GPLv2 as a key aspect of Linux success.

              Of course this doesn't have to be an issue either way, if the kernel devs are fine with this licence then there's really nothing else to say. They set the rules for how to enforce the licencing as they are the copyright holders, gpl-violations which reported this licence incompability has no sway and neither does FSF, again it's up to the copyright holders (Linux devs).

              Beyond that, judging by the mailing-list exchange this floating point emulation is mostly being done in user-space these days and as such it seems likely this in-kernel library will be deprecated anyway, so very much a storm in a teacup. The real action in the mailing list was the angry spat between Russel King and Måns Rullgård, what was that about?
              Linux License CANT change. EVERY single contributor EVER would have to okay the license change and any licensee who refused or couldnt be contacted would have to have every commit they ever did redone by someone else who DID agree to the license change. Thats one of the upsides of a CLA (i dont really agree with them over all, just pointing out that a license change is easy for CLA projects). For that same reason its why im leery of linus' attitude of "GPL v2 and only." because a better license may come along that addresses a real problem with the GPLv2 and then its a giant pain in the ass to move to that new license.

              Comment


              • #27
                There is a difference between saying (paraphrased) "If you use this code, you agree to indemnify XYZ..." and (paraphrased) "Use of this software is restricted to people who will indemnify XYZ...". One makes the implicit assumption that if you use the code, you have already agreed to indemnify the original authors. The other states that you cannot use it unless you do so. This is probably what the FSF is having issues with.

                Comment


                • #28
                  What does this mean for me?

                  Damn, I run a Globalscale Dreamplug as my main fileserver.

                  I'd recently just spent some time learning how to update the u-boot and configure & compile a new linux 3.8 kernel. It's a Marvell Kirkwood - running a Feroceon 88FR131 - an ARMv5te processor. It doesn't have a hardware FPU and any FP ops are currently done with emulation. Until now, I was looking forward to the 3.9 kernel release as I heard changes had been merged to provide CPU frequency stepping for this processor so it would use a tiny bit less power and give off slightly less heat when it's idle.

                  Assuming I did upgrade to the 3.9 kernel when it's out of RC, does anyone know what I could expect would break without software FP emulation?
                  I noticed that RealNC stated somewhere in this thread:
                  This is handled by userspace FP library nowadays, so the change doesn't really break anything in the long run.
                  I know before I updated the kernel to 3.8 it was running a custom version of 2.6.33-7. I upgraded mainly because the default install consistently segfaulted when I was trying to use file encryption (I remember trying at least eCryptFS, encFS and one other). I would imagine encryption algorithms are likely to use FP operations and I'm wondering if that custom 2.6.33-7 didn't have software fp emulation compiled in which caused the issue? Does that sound plausible?

                  Comment


                  • #29
                    Originally posted by Kamikaze View Post
                    Damn, I run a Globalscale Dreamplug as my main fileserver.

                    I'd recently just spent some time learning how to update the u-boot and configure & compile a new linux 3.8 kernel. It's a Marvell Kirkwood - running a Feroceon 88FR131 - an ARMv5te processor. It doesn't have a hardware FPU and any FP ops are currently done with emulation. Until now, I was looking forward to the 3.9 kernel release as I heard changes had been merged to provide CPU frequency stepping for this processor so it would use a tiny bit less power and give off slightly less heat when it's idle.

                    Assuming I did upgrade to the 3.9 kernel when it's out of RC, does anyone know what I could expect would break without software FP emulation?
                    I noticed that RealNC stated somewhere in this thread:


                    I know before I updated the kernel to 3.8 it was running a custom version of 2.6.33-7. I upgraded mainly because the default install consistently segfaulted when I was trying to use file encryption (I remember trying at least eCryptFS, encFS and one other). I would imagine encryption algorithms are likely to use FP operations and I'm wondering if that custom 2.6.33-7 didn't have software fp emulation compiled in which caused the issue? Does that sound plausible?
                    I would assume between 2.6.33 incorrectly used some ARM6 or ARM7 instruction or FP or something, and the 3.9 will still correctly avoid those instructions when built for FPUless ARM.

                    As for the kernel support -- Ubuntu ARM is based on Debian ARMHf (hard float) and so would I guess work with 3.8 but not 3.9. Debian's normal armel support is softfloat, and I'd guess most ARM distros are softfloat. I assume there's basically 2 differences: 1) Some GCC flags (whether to shoot out FPU instructions or the equivalent softlib calls). 2) A few apps like ffmpeg probably have VFP and FPU on/off flags.
                    Last edited by hwertz; 04-10-2013, 10:25 PM.

                    Comment


                    • #30
                      Drop older hardware

                      Well recently hardware support for old i386 were dropped.
                      Does anyone really use ARMv4 and ARMv5?
                      Everyone is using ARMv7, except Raspberry Pi which is using old ARMv6.

                      So does this really affect anyone?
                      And those affected can continue run Linux kernel 3.8 for quite a while.

                      Comment

                      Working...
                      X