From eccdd13dd3c812b8f0b3d046ef9d8738df00562a Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 25 Sep 2013 21:45:38 +0200 Subject: IRC. --- open_issues/anatomy_of_a_hurd_system.mdwn | 143 ++++++++++++++++++++++++++++++ 1 file changed, 143 insertions(+) (limited to 'open_issues/anatomy_of_a_hurd_system.mdwn') diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 75a62535..ba72b00f 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.mdwn @@ -660,3 +660,146 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l but as youpi said, it still requires work and nobody's working on it you may want to check l4 fiasco.oc though + + +# System Personality + +## IRC, freenode, #hurd, 2013-07-29 + + over the past few days I gained a new understanding of the Hurd + teythoon: really ? :) + teythoon: That it's a complex and distributed system? ;-) + And at the same time a really simple one? + ;-D + it's just a bunch of mach programs and some do communicate and + behave in a way a posix system would, but that is more a convention than + anything else + tschwinge: yes, kind of simple and complex :) + the right terminology is "system personality" + 11:03 < teythoon> over the past few days I gained a new + understanding of the Hurd + teythoon: still no answer on that :) + braunr: ah, I spent lot's of time with the core servers and + early bootstrapping and now I gained the feeling that I've seen the Hurd + for what it really is for the first time + + +# RPC Interfaces + +## IRC, freenode, #hurd, 2013-09-03 + + I'm a little confused by the hurd and incubator git repos. + DDE is only found in the dde branch in incubator, but not in the + hurd repo. + Does this mean that DDE is not ready for master yet? + yes + If DDE is not yet used in the hurd (except in the dde branch in + the incubator repo), does pfinet use some custom glue code to use the + Linux drivers? + this has nothing to do with pfinet + pfinet is the networking stack, netdde are the networking drivers + the interface between them doesn't change, whether drivers are in + kernel or not + I see + + +# IRC, freenode, #hurd, 2013-09-20 + + HI there, I have no previous knowledge about OS's. I'm trying to + undestand the structure of the Hurd and the comparison between, say, + Linux way of managing stuff ... + for instance, I read: "Unlike other popular kernel software, the + Hurd has an object-oriented structure that allows it to evolve without + compromising its design." + that means that while for adding feature to the Linux-kernel you + have to add some stuff `inside` a procedure, whilst in the Hurd kernel + you can just, in principle at least, add an object and making the kernel + using it?... + Am I making stuff too simple? + Thanks + not exactly + unix historically has a "file-oriented" structure + the hurd allows servers to implement whatever type they want, + through the ability to create custom interfaces + custom interfaces means custom calls, custom semantics, custom + methods on objects + you're not restricted to the set of file interfaces (open, seek, + read, write, select, close, etc..) that unix normally provides + braunr: uhm ...some example? + see processes for example + see + http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/tree/HEAD:/hurd + this is the collection of interfaces the hurd provides + most of them map to unix calls, because gnu aims at posix + compatibility too + some are internal, like processes + or authentication + but most importantly, you're not restricted to that, you can add + your own interfaces + on a unix, you'd need new system calls + or worse, extending through the catch-all ioctl call + braunr: mhn ...sorry, not getting that. + what part ? + ioctl has become such a mess :s + braunr: when you say that Unix is `file-oriented` you're + referring to the fact that sending/receiving data to/from the kernel is + designed like sending/receiving data to/from a file ...? + not merely sending/receiving + note how formatted your way of thinking is + you directly think in terms of sending/receiving (i.e. read and + write) + braunr: (yes) + that's why unix is file oriented, access to objects is done that + way + on the hurd, the file interface is one interface + there is nothing preventing you from implementing services with a + different interface + as a real world example, people interested in low latency + profesionnal audio usually dislike send/recv + see + http://lac.linuxaudio.org/2003/zkm/slides/paul_davis-jack/unix.html for + example + braunr: how big and messy ioctl has become is a good proof that + the Unix way, while powerful, does have its limits + giuscri: keep in mind the main goal of the hurd is extensibility + without special privileges + braunr: privileges? + root + braunr: what's wrong with privileges? + they allow malicious/buggy stuff to happne + and have dramatic effects + braunr: you're obviously *not* referring to the fact that once + one have the root privileges could change some critical-data + ? + i'm referring to why privilege separation exists in the first + place + if you have unprivileged users, that's because you don't want them + to mess things up + on unix, extending the system requires privileges, giving those + who do it the ability to destroy everything + braunr: yes, I think the same + the hurd is designed to allow unprivileged users to extend their + part of the system, and to some extent share that with other users + although work still remains to completely achieve that + braunr: mhn ...that's the `server`-layer between the + single-application and kernel ? + the multi-server based approach not only allows that, but + mitigates damage even when privileged servers misbehave + one aspect of it yes + but as i was just saying, even root servers can't mess things too + much + for example, our old (sometimes buggy) networking stack can be + restarted when it behaves wrong + the only side effect being some applications (ssh and exim come to + mind) which need to be restarted too because they don't expect the + network stack to be restarted + braunr: ...instead? + ? + giuscri: on Linux, if the network stack crash/freezes, you don't + have any other option than rebooting the system - usually with a nice + "kernel pani" + giuscri: and you may even get filesystem corruption "for free" in + the bundle + and hoping it didn't corrupt something important like file system + caches before being flushed + kilobug, braunr : mhn, ook -- cgit v1.2.3