Announcement

Collapse
No announcement yet.

Genode OS 12.05 Brings Interesting New Features

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

  • Genode OS 12.05 Brings Interesting New Features

    Phoronix: Genode OS 12.05 Brings Interesting New Features

    Genode OS, the popular open-source framework OS, released version 12.05 and it includes several new features like a brand new USB stack, support for the GCC tool-chain, and improved media support...

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

  • #2
    Genode is popular? So, uh, who uses it?

    Comment


    • #3
      Originally posted by jabl View Post
      Genode is popular? [...]
      I'm wondering about this as well. Even wikipedia doesn't know it

      Comment


      • #4
        Admittedly, being involved with the project, I was also a bit (positively) surprised by this statement.

        Comment


        • #5
          Originally posted by Norman Feske View Post
          Admittedly, being involved with the project, I was also a bit (positively) surprised by this statement.
          Has x86_64 support for running Linux been fixed yet? In the past it wouldn't compile.

          Comment


          • #6
            We compile and run Genode on x86_64 (using both the Linux kernel and the Fiasco.OC kernel) on a daily basis. So you might give it another try? If you run into problems, I'd pleased to hear from you via our issue tracker (on GitHub) or the project's mailing list.

            Cheers
            Norman

            Comment


            • #7
              Originally posted by Norman Feske View Post
              We compile and run Genode on x86_64 (using both the Linux kernel and the Fiasco.OC kernel) on a daily basis. So you might give it another try? If you run into problems, I'd pleased to hear from you via our issue tracker (on GitHub) or the project's mailing list.

              Cheers
              Norman
              What I meant is that Fiasco.OC 64-bit compiles without errors as does the Genode framework but the 64-bit Linux kernel, to use in the Genode framework for running Linux programs (the one patched for Genode/Fiasco.OC) doesn't compile. It works if you configure the kernel 32-bit but not 64-bit. At least last time I tried it which was like 3 months ago. On the mailing list, I didn't ask but somone else asked and was told that 64-bit Linux kernel wasn't working yet. That was like 3 months ago.
              Last edited by linux5850; 06-01-2012, 05:05 AM.

              Comment


              • #8
                Thanks for the clarification. This limitation still persists. But it is actually a limitation the L4Linux kernel rather than Genode. L4Linux is a project conducted independently of Genode. It is developed by the OS group at TU Dresden. We adapted this work so that the L4Linux kernel can be integrated with Genode. But our version ultimately inherits the limitations of the upstream project.

                Comment


                • #9
                  Originally posted by Norman Feske View Post
                  Thanks for the clarification. This limitation still persists. But it is actually a limitation the L4Linux kernel rather than Genode. L4Linux is a project conducted independently of Genode. It is developed by the OS group at TU Dresden. We adapted this work so that the L4Linux kernel can be integrated with Genode. But our version ultimately inherits the limitations of the upstream project.
                  One thing you might consider doing to get people interested in Genode is to compose a list of software that will compile natively in the Genode environment, e.g. Firefox, QtDesigner, VLC media player, etc...

                  That way more people will start trying it. Most people care most about being able to play their videos/music and web browsing (preferably Firefox). If Genode can accommodate at least that natively then I think many more people will get involved.

                  Comment


                  • #10
                    You are certainly right. But those applications aren't there yet. I think that the most sensible intermediate step from the perspective of the Genode developers is to use the system for pursuing their development work. Therefore, native support for Unix software is deemed most important at this point. This is why the current development is focused on enabling these tools rather than typical end-user applications.

                    That said, please keep in mind that even though the developers aspire to use the system as general-purpose OS, the primary point of the framework is the creation of special-purpose operating systems. In this domain, the number of ready-to-use components and libraries is of most interest. The components readily available as of now are listed at http://genode.org/documentation/components

                    Comment


                    • #11
                      Device driver environment

                      A couple of things I was wondering about your DDE - have you made any attempt at getting other small OS projects to make use of it too, so as to spread maintenance and testing work? And have you tried getting changes into the Linux kernel to make drivers work more easily with your DDE? I know that the Linux people have traditionally been rather averse to the idea of sharing driver code with other OSes, but perhaps they would not mind as long as they are the upstream and the changes didn't adversely affect the Linux kernel (it would provide additional testing of their kernel driver code too).

                      Comment


                      • #12
                        Originally posted by michael-vb View Post
                        A couple of things I was wondering about your DDE - have you made any attempt at getting other small OS projects to make use of it too, so as to spread maintenance and testing work? And have you tried getting changes into the Linux kernel to make drivers work more easily with your DDE? I know that the Linux people have traditionally been rather averse to the idea of sharing driver code with other OSes, but perhaps they would not mind as long as they are the upstream and the changes didn't adversely affect the Linux kernel (it would provide additional testing of their kernel driver code too).
                        I'm an interested user not a developer of Genode but from I understand pf it the device drivers work in user space not kernel space so it might not be that useful to linux. I don't think linux developers have any problem with sharing driver code with any other GPL project.

                        Comment


                        • #13
                          Originally posted by linux5850 View Post
                          I'm an interested user not a developer of Genode but from I understand pf it the device drivers work in user space not kernel space so it might not be that useful to linux.
                          It will be useful (or not) to Linux only insofar as it provides additional test coverage. Regarding user space and kernel space, code and the way it works is largely independent of which of those two it runs in. Generally the main difference is that compiled kernel space code can execute certain privileged machine instructions which will cause an exception if user space code tries to execute them. However, these tend to be abstracted out of the source code in Linux drivers, as they are different on each CPU architecture the driver will run on anyway, and from that point of view the DDE probably acts as something similar to a new architecture. And of course the set of APIs available to code tend to be very different in user and kernel space, but the whole purpose of the DDE is to hide those differences.

                          The sort of changes I was thinking of when I talked about submitting upstream were more little fiddly things such as changing a driver not to use a kernel API which it doesn't really have to, so that there is one API less to be implemented in the DDE.

                          Comment


                          • #14
                            Because DDE is the glue between Linux code and Genode, the code is specific to both Genode and Linux. However, the code can be classified into two different groups.

                            First, there is code that handles the driver's access to hardware (such as memory-mapped I/O, interrupts, or port I/O). We have indeed a Genode-agnostic API (called DDE kit) for this part. The implementation of DDE kit is Genode-specific but the API is generic. Hence, the part of DDE that translates drivers code to DDE-kit calls is quite independent from Genode and could be subject to be ported to other small OSes.

                            The second part is the code that integrates the high-level driver API with Genode. This code is inherently tied to Genode.

                            With our new DDE for the USB stack, we have not attempted to separate both classes functionality. Our main concern was to keep the DDE as small as possible. But when looking at the code complexity of the new (USB-specific) DDE of less than 4.000 lines of code, I think there is not much of a point in introducing abstraction layers in there.

                            The DDE approach was first implemented by TU Dresden in the TUD:OS research OS. This version was later ported to Minix3 and HURD (and also to the Linux userland, btw). So the general approach to device-driver reuse has been adapted by several groups. There is no centrally managed project though. As explained in the release notes, however, we abandoned the original approach of DDE because it turned out to be hard to maintain and to debug. We are much more confident in our new methodology.

                            Regarding the question on proposing changes to upstream Linux, I am quite happy that the days when we needed to modify the Linux code are over. The new DDE approach completely eliminates the need for such modifications.

                            Comment


                            • #15
                              Originally posted by michael-vb View Post
                              The sort of changes I was thinking of when I talked about submitting upstream were more little fiddly things such as changing a driver not to use a kernel API which it doesn't really have to, so that there is one API less to be implemented in the DDE.
                              That is hard to tell. On the course of constructing the DDE for USB, it becomes apparent that the breadth of the kernel interface referenced by the driver is indeed staggering. Of those functions, however, only a fraction is actually called in our scenario. The list of dummy functions (see dummies.c) is quite telling. All of those functions are somehow called by the driver at some point when used in the Linux kernel. But not in our scenario where we have limited the scope to USB storage and USB HID. Many of the functions are related to code paths that we just don't trigger (i.e., those related to Linux-specific bureaucracy needed to integrate the driver with the Linux kernel, functions specific for power management, or different classes of USB devices). At this point, I find it hard to identify improvements substantial enough to justify a discussion with the Linux kernel developers. Of course, if we found show stoppers or bugs, this would be a different story. But we haven't so far.

                              Comment

                              Working...
                              X