Announcement

Collapse
No announcement yet.

Indian Developers Redesigning Linux Kernel With OOP, C++ Support

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

  • #31
    Originally posted by AllLinux View Post
    I had a look at the "re-engineered" ne2k driver.
    It is just c turned into c++ no OOP.
    class ne2k_pci_oo
    {
    ..
    }
    I would have expected at least someting like
    class ne2k_pci_oo: public pci_driver
    {
    ...
    }
    being a c++ code myself you would have to justify to me what makes an inheritance hierarchy necessary in this case. In my experience any hierarchy with depth more than 2 starts to be a super pain to maintain and follow.

    I could see using a base class with pure virtuals as a tool for forcing implementation of necessary parts of an api but beyond that definitely would need further justification.

    Comment


    • #32
      Originally posted by mdias View Post
      People seem to be throwing arguments randomly...

      [snip]
      The problem of vtables being slow also exit in C.
      [snip]
      C doesn't have vtables. vtables are the implementation permitting virtual method resolution on classes that inherit from others (or are inherited from).

      Originally posted by mdias View Post
      Maybe I missed something about this project, but it seemed to me to be about C++ (code maintainability, syntatic sugar, other C++ pluses), not about stable ABIs?
      That was my impression as well.

      Originally posted by mdias View Post
      C++ also supports functions, not just methods. C++ also supports static methods. I see no reason at all why performance could be lower if the coder knows what he's doing...
      Seeing as how one could write code compatible with pure C in C++, I don't disagree with you. Using C++, one could get all the precision and predictability of C where it matters and the syntactic sugar and readability improvements that are possible with C++. I think there's a mistaken assumption, though, that it is reasonable, good, or valuable to adopt the full capabilities of the language in the kernel.

      Originally posted by mdias View Post
      Plus, we live in an age where people run phone software on top a virtual machine and don't seem to care about the performance hit (yeah, wtf!), so I don't think 1% or 2% slowdown is bad if code maintainability would go up considerably.
      Speak for yourself. My phone runs mostly native code (Android's ART), which, on the benchmarks I've seen, is between 25% and 400% faster than Dalvik and probably about 40% faster on average.

      Comment


      • #33
        Originally posted by david_lynch View Post
        That's actually not the case. Linux drivers have been available as loadable modules since - oh, about 1996 or so, IIRC.
        yes, linux is "modular" as in you can select what driver build into the kernel and what load later - but all belonging to the current kernel release;

        but in general sw engineering, modularity is about creating blocks (with duties according to their ouside interface) and interfaces (separating, and at the same time connecting, blocks as opaque boxes) in order to break down complexity, reuse code, and hide implementation details (so that changes to the working of one unit dont affect others - as long as the interface is untouched)

        in this wider perspective, "modular" actually means "structured" / "compartmentalized" and "orthogonalized" - which linux is not, by design

        Comment


        • #34
          If they use something like rust and iokit for drivers it could be quite interesting.
          OC, this would take an unbelievable amount of work considering the man years that have gone into Linux.
          Linux is far from the most interesting kernel but it works very well, and implementing it in a safe, fast language (with an excellent ffi) with a new, and better, driver framework could be a very useful experiment.

          Comment


          • #35
            What standard of C is the recommended standard for the Linux Kernel? C99, C03? I know C11 won't be introduced for a while.

            If Linux implemented C11: https://en.wikipedia.org/wiki/C11_%2...rd_revision%29

            I doubt anyone would bother using C++ as an option for the kernel.

            Comment


            • #36
              Originally posted by chrisb View Post
              Moving to an object-oriented language is a great idea, but C++ is too old and complicated and programmers would still have to deal with memory allocation. Would be better to use a microkernel with XML API and loadable modern OO language (Java or C#) servlets for all ?kernel modules and drivers. We could call it Fluck, to signify all the objects working together.
              tsk, tsk, you... bringing up Java. Don't you know Java is verboten and banished to the realm of old-person talk? It's all about the Scala revolution now!

              Comment


              • #37
                From someone who's actually developed a USB driver, I can say the following:

                1) The Linux kernel interfaces could benefit from virtual interfaces instead of a struct of pointers.
                2) The use of RAII would rid the Linux kernel of a lot of goto error catching we see, which sometimes leads to some confusing code.
                3) Pretty much any of the C objects could benefit from being a class instead of a POD type. usb_device, usb_interface, input_dev, etc. could easily have member functions and public variables. Hell, even some of the headers implicitly comment "/* Private */" to indicate members which aren't supposed to be accessed from a third-party. Easy enough for me to figure out but would be cool if the language openly supported that.

                But alas, these are minor things. I don't think the Linux kernel made sane decisions when it came to identifier choices which conflict directly with C++, which seems to be for the reason of smiting the thought of using C++.
                That said, it's probably possible to use C++ if you can figure out:
                1) How to get the linker/compiler to generate code the kernel agrees with (which I think can be done with some basic adjustments on the command line).
                2) Figure out which identifiers conflict with C++ and undefine/workaround them.
                3) Make sure your module sees visible symbols with C linkage (which should be as easy as wrapping header inclusions in an (extern "C") block).

                I haven't tried it at all so I'm not sure what other problems you'd run into... just a guess really. Also, that wouldn't change any of the C objects... but it would let you take advantage of RAII and you could maybe create some wrappers yourself that have zero overhead to help with error handling.

                Comment


                • #38
                  Originally posted by johnc View Post
                  tsk, tsk, you... bringing up Java. Don't you know Java is verboten and banished to the realm of old-person talk? It's all about the Scala revolution now!
                  Nope, it's all about Rust and Go now.

                  Comment


                  • #39
                    Originally posted by asavah View Post
                    One of stupidest things I ever read.
                    Run kernel on Java or C#? WTF you were smoking?
                    What about VMs those 2 languages need to run?
                    One by Oracle and another one by MS.
                    Should we embed jre + mono into kernel to run modules?
                    Or should we run kernel modules with userspace runtimes?

                    [sarcasm] Excellent idea for the linux kernel. [/sarcasm]
                    MOSA Project has one repository available. Follow their code on GitHub.

                    Comment


                    • #40
                      Originally posted by jayrulez View Post
                      not open source but there's also this http://en.wikipedia.org/wiki/Midori_(operating_system)

                      Comment

                      Working...
                      X