Announcement

Collapse
No announcement yet.

GNU Hurd 0.5, GNU Mach 1.4 Released

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

  • #41
    Not true. It's needed because I really DON'T want any random code to corrupt my network hardware ! (http://lwn.net/Articles/304105/) And because I don't want to take the risk of crashing everything when I try out a new kernel module.
    Also further to this, Genode appears to be superior to the HURD architecturally in almost every way.

    Comment


    • #42
      Originally posted by jayrulez View Post
      So I am a troll because I have a preference? I expected better from you Richard Braun.

      You may need to work on your reading comprehension skills sir.

      Now I'll head back to the hills to herd some goats or something. You can go back to being a dick.
      Now you are a troll.

      Comment


      • #43
        Originally posted by mrugiero View Post
        Can it enforce any given subsystem (not implemented INSIDE the kernel, I mean) to expose things as files?
        Simple way: just don't allow users to create servers and make privileged system servers not expose things as files. That obviously wouldn't be a Hurd-like system.

        Originally posted by mrugiero View Post
        My statement wasn't that one shouldn't focus on performance, but rather that I don't think that's the right design if performance is the top priority.
        Obviously, the microkernel approach trades some performance for features. But still, the "ideal" approach for performance would be all in the kernel. Even monolithic systems are just a compromise trying to balance performance and features. Actually, if we define a microkernel as "the near-minimum amount of software that can provide the mechanisms needed to implement an operating system (OS)", monolithic kernel advocates would say monolithic kernels are microkernels, something we obviously do not agree on. The difference simply lies in the threshold between what we want in the kernel and what we want outside, keeping in mind that each time we move something out, it should be motivated by the introduction of a useful indirection layer such as virtual address spaces and capabilities.

        Originally posted by mrugiero View Post
        It relates to reliability simply because you can take down and restart faulty features without going completely down. At least, that's what I think.
        No, it really has nothing to do with the concept of modularity. What you're describing is resilience. By the way, resilience was never a goal for the Hurd, just a nice side-effect for non-critical servers such as the network stack and non-root file systems.

        Originally posted by mrugiero View Post
        He stated what he likes, not the reasons, so I don't see how showing its flaws can refute the statement.
        Like I said, it was a troll. Let's feed a bit more by linking the statement with "Why is this alternative needed and who needs it ?". Since FreeBSD has practically the same goals as Linux, and their design is also the same, I thought it would be obvious why the Hurd is a nice alternative to have in comparison... But I understand people have their preferences and like to publically defend them. After all, I use the Hurd.

        Originally posted by jayrulez View Post
        I never said you said that.
        OK, let's be completely pedantic. You said I *think* that. I understand there is no way you can say I said it, since I've never said it, but tell me how you know I think it, I'm very much interested. I don't care much about apologies, just get your facts right.

        Originally posted by jayrulez View Post
        So I am a troll because I have a preference? I expected better from you Richard Braun.
        The word "troll" referred to what I said, not you.
        Originally posted by jayrulez View Post
        You may need to work on your reading comprehension skills sir.
        Originally posted by jayrulez View Post
        I did not state that. Also, going by the most popular definitions of a microkernel, those kernels do not fall under that category. You should know well that there are varying definitions for the term "microkernel".
        I know you didn't, but what you say next is wrong nonetheless. XNU is a microkernel based system. The fact that it runs a big BSD on top of it doesn't change that. It's still a monolithic system, with a microkernel, hence the importance of introducing the concept of "multiserver". The word "microkernel" itself can refer to both hybrids and nanokernels (or what some people call "true microkernels"). So yes, I know that well.

        Originally posted by jayrulez View Post
        Also further to this, Genode appears to be superior to the HURD architecturally in almost every way.
        Except in two important areas :

        1/ POSIX compatibility is only achieved by running a legacy system on top of it, restricting communication with the rest of the system, whereas the Hurd provides amazing conformance with little efforts.

        2/ It's noticeably slow, something that was mentioned during FOSDEM this year, probably because of the massive decoupling of objects. While the Hurd is obviously slow, this comes from implementation defects, mainly scalability issues that prevent it from dealing well with the amount of memory modern machines have. By being a little more coarse-grained, the design potentially reduces the amount of communication compared to L4 based systems. IMO, it's a more viable compromise of features/performance, but we'll only know when those issues are fixed in the Hurd.

        Originally posted by jayrulez View Post
        Now I'll head back to the hills to herd some goats or something.
        Yes, you do that, thanks.

        Comment


        • #44
          Originally posted by rbraun View Post
          "Hurd is actually more hybrid-kernel. It doesn't run drivers in separate processes, which is most important for stability.
          If you really want micro-kernel, QNX is your best choice (sadly it is proprietary and is dying)."
          Partially true. GNU Mach (not the Hurd) is a hybrid because it implements capabilities, high level virtual memory (memory allocation, copy on write, anonymous memory), resource containers (tasks), complex thread scheduling, and most device drivers. That is still too much to consider it a true microkernel like L4. On the other hand, a hybrid has its advantages since it allows reducing the amount of communication for things we may not want to replace by a userspace implementation (just look at how many operations and servers are involved for a mere malloc on an L4 based system). I agree QNX is a good implementation to consider, although it's still not a true microkernel by modern standards, since it also implements capabilities (channels and connections) in the kernel, unless I'm mistaken.
          I think moving drivers out of kernel would make it quite microkernel.

          I really hope we will get some decent microkernel unix-like OS some day.

          Comment


          • #45
            Originally posted by ArneBab View Post
            Now you are a troll.
            No, you're a troll.

            Comment


            • #46
              Originally posted by LightBit View Post
              I think moving drivers out of kernel would make it quite microkernel.

              I really hope we will get some decent microkernel unix-like OS some day.
              Microkernels are not about the size of the kernel. E.g.: You could move all the drivers from the Linux kernel to userspace and it would still be monolithic.

              Comment


              • #47
                Originally posted by jayrulez View Post
                Microkernels are not about the size of the kernel.
                Indeed, otherwise Plan 9 would be microkernel.

                Originally posted by jayrulez View Post
                E.g.: You could move all the drivers from the Linux kernel to userspace and it would still be monolithic.
                No, it would be some weird "hybrid" and I was talking about Mach.

                Comment


                • #48
                  OK, let's be completely pedantic. You said I *think* that. I understand there is no way you can say I said it, since I've never said it, but tell me how you know I think it, I'm very much interested. I don't care much about apologies, just get your facts right.
                  <gnu_srs> And you will address the design flaws or implementation faults
                  with x15?
                  <braunr> no
                  <braunr> i'll address the implementation details
                  <braunr> and some design issues like cpu and memory resource accounting
                  <braunr> but i won't implement generic resource containers
                  <braunr> assuming it's completed, my work should provide a hurd system on
                  par with modern monolithic systems
                  <braunr> (less performant of course, but performant, scalable, and with
                  about the same kinds of problems)
                  <braunr> for example, thread migration should be mandatory
                  <braunr> which would make client calls behave exactly like a userspace task
                  asking a service from the kernel
                  <braunr> you have to realize that, on a monolithic kernel, applications are
                  clients, and the kernel is a server
                  <braunr> and when performing a system call, the calling thread actually
                  services itself by running kernel code
                  <braunr> which is exactly what thread migration is for a multiserver system
                  <braunr> thread migration also implies sync IPC
                  <braunr> and sync IPC is inherently more performant because it only
                  requires one copy, no in kernel buffering
                  <braunr> sync ipc also avoids message floods, since client threads must run
                  server code
                  <gnu_srs> and this is not achievable with evolved gnumach and/or hurd?
                  <braunr> well that's not entirely true, because there is still a form of
                  async ipc, but it's a lot less likely
                  <braunr> it probably is
                  <braunr> but there are so many things to change i prefer starting from
                  scratch
                  <braunr> scalability itself probably requires a revamp of the hurd core
                  libraries
                  <braunr> and these libraries are like more than half of the hurd code
                  <braunr> mach ipc and vm are also very complicated
                  <braunr> it's better to get something new and simpler from the start
                  <gnu_srs> a major task nevertheless:-D
                  <braunr> at least with the vm, netbsd showed it's easier to achieve good
                  results from new code, as other mach vm based systems like freebsd
                  struggled to get as good
                  <braunr> well yes
                  <braunr> but at least it's not experimental
                  <braunr> everything i want to implement already exists, and is tested on
                  production systems
                  <braunr> it's just time to assemble those ideas and components together
                  into something that works
                  <braunr> you could see it as a qnx-like system with thread migration, the
                  global architecture of the hurd, and some improvements from linux like
                  rcu
                  I know you didn't, but what you say next is wrong nonetheless. XNU is a microkernel based system. The fact that it runs a big BSD on top of it doesn't change that. It's still a monolithic system, with a microkernel, hence the importance of introducing the concept of "multiserver". The word "microkernel" itself can refer to both hybrids and nanokernels (or what some people call "true microkernels"). So yes, I know that well.
                  Did you say pedantic earlier?

                  1/ POSIX compatibility is only achieved by running a legacy system on top of it, restricting communication with the rest of the system, whereas the Hurd provides amazing conformance with little efforts.
                  Obviously, POSIX compatibility is not a goal of Genode. POSIX compatibility is added on a as needed basis. For example: to allow Qt and other ported libraries.

                  2/ It's noticeably slow, something that was mentioned during FOSDEM this year, probably because of the massive decoupling of objects. While the Hurd is obviously slow, this comes from implementation defects, mainly scalability issues that prevent it from dealing well with the amount of memory modern machines have. By being a little more coarse-grained, the design potentially reduces the amount of communication compared to L4 based systems. IMO, it's a more viable compromise of features/performance, but we'll only know when those issues are fixed in the Hurd.
                  The slowness in Genode also come from implementation defects, however, without the scalability issues present in HURD.
                  For example: about 3 weeks ago, a commit was made which resulted in more than 2.5x speed increase when running the toolchain(that is compiling genode on genode) for the core on the NOVA kernel.

                  Comment


                  • #49
                    Originally posted by jayrulez View Post
                    Did you say pedantic earlier?
                    Good job for such a big post without pointing out what you actually wanted to say.

                    Comment

                    Working...
                    X