summaryrefslogtreecommitdiff
path: root/open_issues/mach_federations.mdwn
blob: 50c939c3171f9736e6b9e63e2765f764ba0f09a8 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
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.