summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
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.mdwn45
-rw-r--r--open_issues/multiprocessing.mdwn18
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