diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/benefits_of_a_native_hurd_implementation.mdwn (renamed from open_issues/benefits.mdwn) | 85 | ||||
| -rw-r--r-- | open_issues/implementing_hurd_on_top_of_another_system.mdwn | 45 | ||||
| -rw-r--r-- | open_issues/multiprocessing.mdwn | 18 |
3 files changed, 75 insertions, 73 deletions
diff --git a/open_issues/benefits.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn index da1248c8..34e49e86 100644 --- a/open_issues/benefits.mdwn +++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn @@ -11,60 +11,61 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] What are the benefits of a native GNU/Hurd system, now that Linux et al. can do -so much (think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux, -etc.). +so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux +and other virtualization techiques, and so on. It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but... IRC, #hurd, August / September 2010 <marcusb> ArneBab: but Neal and I were not happy with that alone. We were - looking for deeper improvements to the system, for, I think, sound reasons. - That is what brought us to the L4/Coyotos technologies - <marcusb> ArneBab: as you are writing a kernel in user space, you can still do - kernel improvements there - <marcusb> ArneBab: if you take it very far, you end up with a kernel that runs - Linux in user space (just flip the two) for the drivers + looking for deeper improvements to the system, for, I think, sound + reasons. That is what brought us to the L4/Coyotos technologies + <marcusb> ArneBab: as you are writing a kernel in user space, you can still + do kernel improvements there + <marcusb> ArneBab: if you take it very far, you end up with a kernel that + runs Linux in user space (just flip the two) for the drivers <marcusb> ArneBab: that is what the L4 people did with the DDE ([[DDE]]) <marcusb> ArneBab: so, with these different cuts, there are different - opportunities. on the one end, you can run Linux as normal and get some of - the Hurd features such as translators in some programs. At the other end, - you can do whatever you want and run some linux code for the drivers or none - at all. - <marcusb> ArneBab: one of the big questions then becomes: at which point can - the advantages offered by the Hurd be realized? + opportunities. on the one end, you can run Linux as normal and get some + of the Hurd features such as translators in some programs. At the other + end, you can do whatever you want and run some linux code for the drivers + or none at all. + <marcusb> ArneBab: one of the big questions then becomes: at which point + can the advantages offered by the Hurd be realized? <marcusb> ArneBab: and that's not entirely clear to me - <marcusb> when I worked on this with Neal, we pushed further and further into - need-to-change-everything land - <marcusb> while the current efforts on the Hurd seem to be more equivalent to - the could-run-it-in-userspace-on-top-of-Linux camp - <ArneBab> marcusb: for that I think we need a way to move towards them step by - step. Would it be possible to get the advantages of better resource + <marcusb> when I worked on this with Neal, we pushed further and further + into need-to-change-everything land + <marcusb> while the current efforts on the Hurd seem to be more equivalent + to the could-run-it-in-userspace-on-top-of-Linux camp + <ArneBab> marcusb: for that I think we need a way to move towards them step + by step. Would it be possible to get the advantages of better resource allocation with a Viengoos in userspace, too? <ArneBab> and when that is stable, just switch over? - <marcusb> ArneBab: I don't know. I suspect these people will know before us: - http://lxc.sourceforge.net/ - <ArneBab> something like implementing flip points: flip Linux with Hurd to Hund - with Linux. Flip Mach with L4 to L4 with Mach. + <marcusb> ArneBab: I don't know. I suspect these people will know before + us: http://lxc.sourceforge.net/ + <ArneBab> something like implementing flip points: flip Linux with Hurd to + Hund with Linux. Flip Mach with L4 to L4 with Mach. <ArneBab> lxc sounds interesting. <marcusb> note that these efforts address security concerns more than other concerns <marcusb> so they will get isolation long before sharing is even considered <marcusb> but some of the issues are the same - <marcusb> once you allow malware to do what it wants, it's a small step to also - allow the user to what he wants :) + <marcusb> once you allow malware to do what it wants, it's a small step to + also allow the user to what he wants :) <ArneBab> it kinda looks like hacking it where it doesn’t really fit again… - <ArneBab> there I ask myself when the point comes that doing a cleaner design - offsets the popularity + <ArneBab> there I ask myself when the point comes that doing a cleaner + design offsets the popularity <ArneBab> they are pushing more and more stuff into userspace <ArneBab> which is a good thing (to me) - <ArneBab> it’s hard to clearly describe how, but even though I like having more - stuff in userspace, the way it is bolted onto Linux doesn’t feel good for me. - <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to a - non-fuse user + <ArneBab> it’s hard to clearly describe how, but even though I like having + more stuff in userspace, the way it is bolted onto Linux doesn’t feel + good for me. + <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to + a non-fuse user <ArneBab> while in the Hurd, these additional options are on eqal footing. <marcusb> ArneBab: are they pushing more and more into user space? I don't think so. I see more of the reverse, actually @@ -74,13 +75,13 @@ IRC, #hurd, August / September 2010 <ArneBab> to avoid flickering when switching between X and the console? <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in Linux, too, or is that just a strange feeling of me? - <ArneBab> marcusb: and that splits the users into those who can get stuff into - the kernel and those who can only work in userspace – which I don’t really - like. - <ArneBab> That’s one more advantage of the Hurd: eqal footing for all (except - the Mach hackers, but they have a very limited terrain) - <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have a - principled objection to it (but just wanted a more general solution) - <marcusb> ArneBab: as a side note, although people keep complaining, the linux - kernel seems to be growing steadily, so getting stuff into the kernel doesn't - seem too hard. 8-O + <ArneBab> marcusb: and that splits the users into those who can get stuff + into the kernel and those who can only work in userspace – which I don’t + really like. + <ArneBab> That’s one more advantage of the Hurd: eqal footing for all + (except the Mach hackers, but they have a very limited terrain) + <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have + a principled objection to it (but just wanted a more general solution) + <marcusb> ArneBab: as a side note, although people keep complaining, the + linux kernel seems to be growing steadily, so getting stuff into the + kernel doesn't seem too hard. 8-O diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn index 1d7a1e50..7e88e322 100644 --- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn +++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn @@ -21,8 +21,8 @@ IRC, #hurd, August / September 2010 <marcusb> silver_hook: the Hurd can also refer to the interfaces of the filesystems etc, and a lot of that is really just server/client APIs that - could be implemented on any system that has transferable rights to message - capabilities. + could be implemented on any system that has transferable rights to + message capabilities. <marcusb> silver_hook: it's surprising how few systems *have* transferable rights, though! <marcusb> silver_hook: usually it is added as an afterthought @@ -33,23 +33,24 @@ IRC, #hurd, August / September 2010 <marcusb> youpi: it's described in the Stevens series even [...] <marcusb> ArneBab: well, let me put it this way. the Linux kernel has no - interface to manipulate another tasks's virtual address space, ie you can't - map/unmap stuff in another process - <marcusb> ArneBab: you would have to use ptrace and load some stub code in that - process to make that happen. - <marcusb> ArneBab: so for complete transparent manipulation, you need a kernel - module + interface to manipulate another tasks's virtual address space, ie you + can't map/unmap stuff in another process + <marcusb> ArneBab: you would have to use ptrace and load some stub code in + that process to make that happen. + <marcusb> ArneBab: so for complete transparent manipulation, you need a + kernel module <marcusb> that is what the User Mode Linux kernel module does - <marcusb> ArneBab: so say you use the User Mode Linux kernel module for that - one feature. Then you can do everything that User Mode Linux can do, which, - I assure you, includes running subhurds :) + <marcusb> ArneBab: so say you use the User Mode Linux kernel module for + that one feature. Then you can do everything that User Mode Linux can + do, which, I assure you, includes running subhurds :) <marcusb> it can be a bit tricky to implement those features, but it is not harder than writing a kernel in the first place - <ArneBab> So, if I got an admin to install User Mode Linux and Mach emulation, - I’d get the flexibility (and independence from admin decisions) I have in the - Hurd? - <marcusb> ArneBab: one problem is that you still use Linux. For those who want - to get rid of Linux for political reasons, that would mean complete failure + <ArneBab> So, if I got an admin to install User Mode Linux and Mach + emulation, I’d get the flexibility (and independence from admin + decisions) I have in the Hurd? + <marcusb> ArneBab: one problem is that you still use Linux. For those who + want to get rid of Linux for political reasons, that would mean complete + failure <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in user space <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or @@ -57,10 +58,10 @@ IRC, #hurd, August / September 2010 ([[tschwinge]] has tarballs of John's work.) - <marcusb> ArneBab: or you can just implement parts of it and relay to Linux for - the rest - <marcusb> the point is, that if you don't care for kernel improvements, and are - sufficiently happy with the translator stuff, it's not hard to bring the Hurd - to Linux or BSD + <marcusb> ArneBab: or you can just implement parts of it and relay to Linux + for the rest + <marcusb> the point is, that if you don't care for kernel improvements, and + are sufficiently happy with the translator stuff, it's not hard to bring + the Hurd to Linux or BSD -(Continue: [[benefits]].) +Continue reading about the [[benefits of a native Hurd implementation]]. diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 7b4f2611..224c0826 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, -microkernel-based multi-server systems in particular, would be ideal condidates +microkernel-based multi-server systems in particular, would be ideal candidates for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. @@ -19,14 +19,14 @@ inexperienced point of view: there are many difficulties. IRC, #hurd, August / September 2010 <marcusb> silver_hook: because multi-server systems depend on inter-process - communication, and inter-process communication is many times more expensive - across cpus - <marcusb> silver_hook: so you either force interrelated work on the same cpu, - or suffer heavy penalties. and in a typical fine-grained object system, all - objects are interconnected! - <marcusb> silver_hook: resources in today's systems, even in a single node with - one cpu, but more so in a network, are very non-uniform. scheduling these - resources efficiently is a huge problem. restricting the resource + communication, and inter-process communication is many times more + expensive across cpus + <marcusb> silver_hook: so you either force interrelated work on the same + cpu, or suffer heavy penalties. and in a typical fine-grained object + system, all objects are interconnected! + <marcusb> silver_hook: resources in today's systems, even in a single node + with one cpu, but more so in a network, are very non-uniform. scheduling + these resources efficiently is a huge problem. restricting the resource distribution policies in the way microkernel systems tend to do is posing serious research challenges |