Announcement

Collapse
No announcement yet.

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

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

  • #11
    Not very OOP

    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
    {
    ...
    }

    Comment


    • #12
      Originally posted by uid313 View Post
      Mostly to filter out idiots so dumb people don't contribute to the kernel.
      He wants a high barrier to entry to weed out crappy programmers.
      According to kernel git log, It looks like many kernel developers are either incompetent, inexperienced or idiots because of their lax development process.

      Comment


      • #13
        Originally posted by Min1123 View Post
        So the conversation here, as I understand it, is that someone is making a fork of the Linux kernel that allows for device drivers to be separate from the kernel.
        I don't get it. You can already create drivers that are separate from the kernel. You can also use dkms to help you with different kernels.

        Comment


        • #14
          Another useless tons of work. Would be better if some one tried to make Linux a micro-kernel.

          Comment


          • #15
            Separate for reasons

            Originally posted by mdias View Post
            I don't get it. You can already create drivers that are separate from the kernel. You can also use dkms to help you with different kernels.
            The drivers that are separate from the kernel tend to fall into two camps:
            1) Not to standards or not good enough for inclusion into mainline
            2) Does not comply with the spirit of the license

            GPLv2 is in use for the Linux kernel because it has some portions in it that were later considered to be loopholes by FSF when they made GPLv3. The main reason stated was binary drivers and shims, such as proprietary graphics drivers.
            Others are things licensed under some other incompatible license like ZFS.

            The other code isn't written with the formatting, or uses incorrect APIs, or reimplements things that they shouldn't reimplement.

            Any code that can be mainlined for drivers or such is mainlined, and then is distributed with the kernel. Support doesn't have to be compiled in (to the kernel or to modules), but over time the amount of hardware and architectures has grown, and the kernel has grown with it.

            I feel that any separation done to be more modular would be a great benefit to the kernel, and the production of an ABI to allow for longer term commercial drivers would be very beneficial (if used). This could be a first couple steps towards making that happen.

            Comment


            • #16
              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
              {
              ...
              }
              Ha, they got all of the overhead, and none of the benefits! But this is early code.

              Seriously, today we have the Hurd which sounds great from a design standpoint great but has made no progress, and we have Linux which has conquered the world, but is rather ugly from a design standpoint. Like it was mentioned above by others, Linux needs, not just driver modules, which have been a huge improvement, but also a clean API for divers to be developed outside, and loosely coupled with, the kernel guts.

              I think it's ok for the guts of the kernel to be written in C, but a ton of the code should be pushed outside, and use OOP and communicate via clean API's. C is a subset of C++, so it feels like it should be possible to keep everybody (Linus and Friends, and Driver developers) happy.

              Comment


              • #17
                Originally posted by mendieta View Post
                Ha, they got all of the overhead, and none of the benefits! But this is early code.

                Seriously, today we have the Hurd which sounds great from a design standpoint great but has made no progress, and we have Linux which has conquered the world, but is rather ugly from a design standpoint. Like it was mentioned above by others, Linux needs, not just driver modules, which have been a huge improvement, but also a clean API for divers to be developed outside, and loosely coupled with, the kernel guts.

                I think it's ok for the guts of the kernel to be written in C, but a ton of the code should be pushed outside, and use OOP and communicate via clean API's. C is a subset of C++, so it feels like it should be possible to keep everybody (Linus and Friends, and Driver developers) happy.
                At the moment drivers are the biggest problem for me.
                Every new driver copy chunks of code from existing drivers and tweak it for the new driver.
                In that sense something like C++/OOP would let you inherit standard code (ie. read/write/open/seek etc) and override what you need to change for the new driver.
                There should be base classes for char/block etc.

                The arguments against something like this is as old as my children ;-)

                Comment


                • #18
                  As much as I'm all for C++ing the kernel and reducing the complexity of the kernel through OOP techniques, they should have picked a different kernel to do this. Linux changes way too fast, the pre-existing code base is too big for just a few people to convert, and the upstream is hostile to C++ and OOP which means that this is going to be a permanent fork which is going to require a lot of work for them to maintain.

                  Comment


                  • #19
                    Originally posted by mendieta View Post
                    Ha, they got all of the overhead, and none of the benefits! But this is early code.

                    Seriously, today we have the Hurd which sounds great from a design standpoint great but has made no progress, and we have Linux which has conquered the world, but is rather ugly from a design standpoint. Like it was mentioned above by others, Linux needs, not just driver modules, which have been a huge improvement, but also a clean API for divers to be developed outside, and loosely coupled with, the kernel guts.

                    I think it's ok for the guts of the kernel to be written in C, but a ton of the code should be pushed outside, and use OOP and communicate via clean API's. C is a subset of C++, so it feels like it should be possible to keep everybody (Linus and Friends, and Driver developers) happy.
                    Converting structs to classes is just about the *lowest* overhead way of using C++.

                    RTTI and exception handling are *extremely* difficult to get right in the kernel and add a lot of processing overhead. Templates don't theoretically have any meaningful impact on code execution time, but they can very easily unintentionally multiply code size and memory usage. Vtables are generally problematic for performance because they lead to page faults and cache misses. Not to mention that fact that stack usage will likely balloon, pushing the per-thread stack usage up beyond even the current (expanded) limits, and increasing the size of thread stacks would cause page allocations to wind up taking even longer. And each and every one of the above is bad for determinism and jitter, making it unsuitable for many embedded uses, at the very least. And if you lose the embedded developers you lose the single largest source of funding and developers for the linux kernel, not to mention the group with the greatest interest in keeping the kernel small and fast.
                    Last edited by DataPath; 03 October 2014, 01:01 PM.

                    Comment


                    • #20
                      Re

                      They didn't take 1 thing in consideration: Low-level people, hardware people(embedded guys for example) hate with passion C++ and the other higher level programming languages.

                      I was talking to some embedded developers, for them C++ seemed something from a fantasy world(One guy was claiming that if it's C++ it's consuming automatically more memory - which is absolute non-sense). Because they were educated to program in C, they strongly believe that you can't write for embedded in C++... I was explaining that you can and there are companies that write in C++(like Boeing) and their next argument was "Then why do all the people at [that automotive company] write in C?" - simple, old people teach old techniques and technologies and it's passed on. Same problem that happens with C++ - people don't get taught modern C++ and then you hear people complaining about memory management for example...

                      Comment

                      Working...
                      X