summaryrefslogtreecommitdiff
path: root/open_issues/robustness.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/robustness.mdwn')
-rw-r--r--open_issues/robustness.mdwn65
1 files changed, 65 insertions, 0 deletions
diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn
index d32bd509..1f8aa0c6 100644
--- a/open_issues/robustness.mdwn
+++ b/open_issues/robustness.mdwn
@@ -62,3 +62,68 @@ License|/fdl]]."]]"""]]
<antrik> well, I'm not aware of the Minix implementation working across
reboots. the one I have in mind based on a generic session management
infrastructure should though :-)
+
+
+## IRC, freenode, #hurd, 2012-12-06
+
+ <Tekk_> out of curiosity, would it be possible to strap on a resurrection
+ server to hurd?
+ <Tekk_> in the future, that is
+ <braunr> sure
+ <Tekk_> cool :)
+ <braunr> but this requires things like persistence
+ <spiderweb> like a reincarnation server?
+ <braunr> it's a lot of works, with non negligible overhead
+ <Tekk_> spiderweb: yes, exactly. I didn't remember tanenbaum's wording on
+ that
+ <braunr> i'm pretty sure most people would be against that
+ <spiderweb> braunr: why so?
+ <Tekk_> it was actually the feature that convinced me that ukernels were a
+ good idea
+ <Tekk_> spiderweb: because then you need a process that keeps track of all
+ the other servers
+ <Tekk_> and they have to be replying to "useless" pings to see if they're
+ still alive
+ <braunr> spiderweb: the hurd community isn't looking for a system reliable
+ in critical environments
+ <braunr> just a general purpose system
+ <braunr> and persistence requires regular data saves
+ <braunr> it's expensive
+ <Tekk_> as well as that
+ <braunr> we already have performance problems because of the nature of the
+ system, adding more without really looking for the benefits is useless
+ <spiderweb> so you can't theoretically have both?
+ <braunr> persistence and performance ?
+ <braunr> it's hard
+ <Tekk_> spiderweb: you need to modify the other translators to be
+ persistent
+ <braunr> only the ones you care about actually
+ <braunr> but it's just better to make the critical servers very stable
+ <Tekk_> so it's not just turning on and off the reincarnation
+ <braunr> (there isn't that much code there)
+ <braunr> and the other servers restartable
+ <mcsim> braunr: I think that if there will be aim to make something like
+ resurrection server than it will be needed rewrite most servers to make
+ them stateless, isn't it?
+ <braunr> that's a lot easier and already works with non essential passive
+ translators
+ <Tekk_> mcsim: pretty much
+ <braunr> mcsim: only those you care about
+ <braunr> mcsim: the proc auth exec servers for example, perhaps the file
+ system servers that can act as root fs, but the others would simply be
+ restarted by the passive translator mechanism
+ <spiderweb> what about restarting device drivers, that would be simple
+ right?
+ <braunr> that's perfectly doable, yes
+ <spiderweb> (being an OS newbie) - it does seem to me that the whole
+ reincarnation server concept could quite possibly be a band aid.
+ <braunr> spiderweb: no it really works
+ <braunr> many systems do that actually
+ <braunr> let me give you a link
+ <braunr>
+ http://ftp.sceen.net/curios_improving_reliability_through_operating_system_structure.pdf
+ <braunr> it's a bit old, but there is a review of systems aiming at
+ resilience and how they achieve part of it
+ <spiderweb> neat, thanks
+ <braunr> actually it's not that old at all
+ <braunr> around 2007