Announcement

Collapse
No announcement yet.

GNU Hurd 0.5, GNU Mach 1.4 Released

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

  • #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