Announcement

Collapse
No announcement yet.

Lua Scripting Support Being Added To NetBSD Kernel

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

  • Lua Scripting Support Being Added To NetBSD Kernel

    Phoronix: Lua Scripting Support Being Added To NetBSD Kernel

    Support for the Lua scripting language is being added to the NetBSD kernel so that it's possible to interact with the BSD kernel's various subsystems using this popular scripting language. With a Lua interpreter being added to the kernel, it's even possible to extend the kernel's subsystems in this scripting language...

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

  • #2
    The NetBSD devs noted that they plan to write their nouveau graphics driver in Lua since you don't have to deal with memory leaks any longer, which makes it superior to the Linux implementation. Also parts of ZFS and the audio stack will be ported to Lua for its advanced flexibility and productivity compared to C.

    Comment


    • #3
      This is actually pretty cool. I just hope they use a fast interpreter or JIT compiler. I have microbenchmarked LuaJIT and was utterly impressed by the speed of the code. It was more often than not faster than GCC or Clang compiled C++.

      Comment


      • #4
        Originally posted by LinuxID10T View Post
        This is actually pretty cool. I just hope they use a fast interpreter or JIT compiler. I have microbenchmarked LuaJIT and was utterly impressed by the speed of the code. It was more often than not faster than GCC or Clang compiled C++.
        How can Lua (LuaJIT) be so fast?

        Anyone ever wrote a kernel in Lua?

        There is an operating systems such as JNode and JX which are written in Java.
        Singularity, Cosmos and SharpOS which are written in C#.

        Comment


        • #5
          Originally posted by uid313 View Post
          How can Lua (LuaJIT) be so fast?

          Anyone ever wrote a kernel in Lua?

          There is an operating systems such as JNode and JX which are written in Java.
          Singularity, Cosmos and SharpOS which are written in C#.
          I personally had no clue why it was so fast, which made myself all the more interested in it. I am guessing that it is just very, very highly optimized for speed. You also have to remember just how small of a language Lua is. Since it is so small, my guess is that it is far easier to optimize each operation. Using the official interpreter often took five minutes to do what LuaJIT did for me in ~16 seconds. For that same benchmark, GCC took about 22 seconds and Clang 26 seconds. If you want the code for my microbenchmarks, ask and I can post it on Pastebin.

          I'm not sure if anyone has written a kernel in Lua, but for a while I was considering doing so myself. I don't think it would be very difficult at all. In fact, it would probably be significantly easier than Java or C#.
          Last edited by LinuxID10T; 02-14-2013, 11:10 AM.

          Comment


          • #6
            maybe they can add a web browser and an email client while they are at it

            Comment


            • #7
              In NetBSD the word "kernel" has lost its meaning.

              "Kernel" means "hard durable core"

              NetBSD has no "kernel" any more, it's soft mush all the way to the middle.

              Comment


              • #8
                horrible

                language interpreters are "infinite bug sponges". You squeeze them and bugs pour out. You can squeeze and squeeze for years and you will get an unending stream of bugs. Don't believe me? Look at any "mature" interpreted language, go visit its bug database. This is bad because kernels are supposed to be sanctuaries of quality code, not infestations of bugs.

                Comment


                • #9
                  Is this 1985 or something? What is the point of interpreting? Why not just recompile? We all have gigahertz processors and we use SS drives. It's not like it takes hours to recompile a kernel module like it did back in the 80's. We have awesome debugging tools now, so debugging kernel code is not the nightmare it was in 1985. vmware kernel modules compile themselves and install in a minute, and they are very extensive. I think these BSD people live in some distant past.

                  Comment


                  • #10
                    that's the stupiest idea i heard in a long long time.

                    Comment


                    • #11
                      Originally posted by frantaylor View Post
                      language interpreters are "infinite bug sponges". You squeeze them and bugs pour out. You can squeeze and squeeze for years and you will get an unending stream of bugs. Don't believe me? Look at any "mature" interpreted language, go visit its bug database. This is bad because kernels are supposed to be sanctuaries of quality code, not infestations of bugs.
                      I think you are overgeneralizing. First off, Lua has a VERY small codebase. Second off, it matters about the project, not the type of project.

                      Comment


                      • #12
                        Originally posted by frantaylor View Post
                        Is this 1985 or something? What is the point of interpreting? Why not just recompile? We all have gigahertz processors and we use SS drives. It's not like it takes hours to recompile a kernel module like it did back in the 80's. We have awesome debugging tools now, so debugging kernel code is not the nightmare it was in 1985. vmware kernel modules compile themselves and install in a minute, and they are very extensive. I think these BSD people live in some distant past.
                        This makes a lot more sense now. Interpreted languages take far more processor strength than compiled languages. You have the whole idea completely backwards. Furthermore, one of the largest things that they stated was to make it easier for the average user to be able to interface with the kernel.

                        Comment


                        • #13
                          Originally posted by LinuxID10T View Post
                          I think you are overgeneralizing. First off, Lua has a VERY small codebase. Second off, it matters about the project, not the type of project.
                          The language is exposing inner parts of BSD to the programmer and so you have to count all of that code area into your analysis. You are going to be taking kernel function calls that previously only been called by other parts of the kernel, and you are opening them up for general use. So you've basically folded the kernel into the language, and every user-accessible API is now going to be passed arbitrary input. In order to make this fly, you are going to need to write a whole new set of regression tests for every single API function that you've exposed.

                          You are aware that the code for full regression testing is bigger and requires more manpower than the code it tests? They've bought themselves into a testing nightmare. It's going to be regression after regression because there is no way they will have the time or the manpower or the inclination to do full regression testing before every release.

                          Maybe you have seen other instances where programming languages have been mashed up with big existing systems? Have you ever seen one of these that wasn't a nightmare? When I think of programming languages that offer extended capabilities, I think of Flash and Java and .Net, and all of these products are testing nightmares.
                          Last edited by frantaylor; 02-14-2013, 04:55 PM.

                          Comment


                          • #14
                            Originally posted by mark45 View Post
                            The NetBSD devs noted that they plan to write their nouveau graphics driver in Lua since you don't have to deal with memory leaks any longer, which makes it superior to the Linux implementation. Also parts of ZFS and the audio stack will be ported to Lua for its advanced flexibility and productivity compared to C.
                            You're just kidding, right?

                            Comment


                            • #15
                              Originally posted by Pawlerson View Post
                              You're just kidding, right?
                              They are trying to recreate that "Sun-3" experience because that was the last time anybody used it.

                              Comment

                              Working...
                              X