summaryrefslogtreecommitdiff
path: root/open_issues/mach_federations.mdwn
diff options
context:
space:
mode:
authorSamuel Thibault <samuel.thibault@ens-lyon.org>2012-12-30 00:36:20 +0100
committerSamuel Thibault <samuel.thibault@ens-lyon.org>2012-12-30 00:36:20 +0100
commite9235e964397bc2c5c6ca1858aba5c098b591660 (patch)
treef105012a160e801e96ec81f2d26b447deb835d08 /open_issues/mach_federations.mdwn
parentd90af7499de9d0c58215691174826f956ff6612c (diff)
parent55ffc6f5698b61c75260ff12b2591e3032b0651e (diff)
Merge branch 'master' of git.savannah.gnu.org:/srv/git/hurd/web
Diffstat (limited to 'open_issues/mach_federations.mdwn')
-rw-r--r--open_issues/mach_federations.mdwn66
1 files changed, 66 insertions, 0 deletions
diff --git a/open_issues/mach_federations.mdwn b/open_issues/mach_federations.mdwn
new file mode 100644
index 00000000..50c939c3
--- /dev/null
+++ b/open_issues/mach_federations.mdwn
@@ -0,0 +1,66 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2012-08-18
+
+ <braunr> well replacing parts of it is possible on the hurd, but for core
+ servers it's limited
+ <braunr> minix has features for that
+ <braunr> this was interesting too:
+ http://static.usenix.org/event/osdi08/tech/full_papers/david/david_html/
+ <braunr> lcc: you'll always have some kind of dependency problems which are
+ hard to solve
+ <savask> braunr: One my friend asked me if it's possible to run different
+ parts of Hurd on different computers and make a cluster therefore. So, is
+ it, at least theoretically?
+ <braunr> savask: no
+ <savask> Okay, then I guessed a right answer.
+ <youpi> well, theorically it's possible, but it's not implemented
+ <braunr> well it's possible everywhere :p
+ <braunr> there are projects for that on linux
+ <braunr> but it requires serious changes in both the protocols and servers
+ <braunr> and it depends on the features you want (i assume here you want
+ e.g. process checkpointing so they can be migrated to other machines to
+ transparently balance loads)
+ <lcc> is it even theoretically possible to have a system in which core
+ servers can be modified while the system is running? hm... I will look
+ more into it. just curious.
+ <savask> lcc: Linux can be updated on the fly, without rebooting.
+ <braunr> lcc: to some degree, it is
+ <braunr> savask: the whole kernel is rebooted actually
+ <braunr> well not rebooted, but restarted
+ <braunr> there is a project that provides kernel updates through binary
+ patches
+ <braunr> ksplice
+ <savask> braunr: But it will look like everything continued running.
+ <braunr> as long as the new code expects the same data structures and other
+ implications, yes
+ <braunr> "Ksplice can handle many security updates but not changes to data
+ structures"
+ <braunr> obviously
+ <braunr> so it's good for small changes
+ <braunr> and ksplice is very specific, it's intended for security updates,
+ ad the primary users are telecommunication providers who don't want
+ downtime
+ <antrik> braunr: well, protocols and servers on Mach-based systems should
+ be ready for federations... although some Hurd protocols are not clean
+ for federations with heterogenous architectures, at least on homogenous
+ clusters it should actually work with only some extra bootstrapping code,
+ if the support existed in our Mach variant...
+ <braunr> antrik: why do you want the support in the kernel ?
+ <antrik> braunr: I didn't say I *want* federation support in the
+ kernel... in fact I agree with Shapiro that it's probably a bad idea. I
+ just said that it *should* actually work with the system design as it is
+ now :-)
+ <antrik> braunr: yes, I said that it wouldn't work on heterogenous
+ federations. if all machines use the same architecture it should work.