diff options
author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2012-12-30 00:36:20 +0100 |
---|---|---|
committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2012-12-30 00:36:20 +0100 |
commit | e9235e964397bc2c5c6ca1858aba5c098b591660 (patch) | |
tree | f105012a160e801e96ec81f2d26b447deb835d08 /open_issues/mach_federations.mdwn | |
parent | d90af7499de9d0c58215691174826f956ff6612c (diff) | |
parent | 55ffc6f5698b61c75260ff12b2591e3032b0651e (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.mdwn | 66 |
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. |