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.
Announcement
Collapse
No announcement yet.
GNU Hurd 0.5, GNU Mach 1.4 Released
Collapse
X
-
Originally posted by jayrulez View PostSo 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.
Comment
-
Originally posted by mrugiero View PostCan it enforce any given subsystem (not implemented INSIDE the kernel, I mean) to expose things as files?
Originally posted by mrugiero View PostMy 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.
Originally posted by mrugiero View PostIt relates to reliability simply because you can take down and restart faulty features without going completely down. At least, that's what I think.
Originally posted by mrugiero View PostHe stated what he likes, not the reasons, so I don't see how showing its flaws can refute the statement.
Originally posted by jayrulez View PostI never said you said that.
Originally posted by jayrulez View PostSo I am a troll because I have a preference? I expected better from you Richard Braun.Originally posted by jayrulez View PostYou may need to work on your reading comprehension skills sir.Originally posted by jayrulez View PostI 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".
Originally posted by jayrulez View PostAlso further to this, Genode appears to be superior to the HURD architecturally in almost every way.
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 PostNow I'll head back to the hills to herd some goats or something.
Comment
-
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 really hope we will get some decent microkernel unix-like OS some day.
Comment
-
Originally posted by LightBit View PostI 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
-
Originally posted by jayrulez View PostMicrokernels are not about the size of the kernel.
Originally posted by jayrulez View PostE.g.: You could move all the drivers from the Linux kernel to userspace and it would still be monolithic.
Comment
-
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.
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.
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
Comment