summaryrefslogtreecommitdiff
path: root/open_issues/implementing_hurd_on_top_of_another_system.mdwn
blob: a3e367cef0d24f75c161e569cbdbfad3b7f08320 (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
[[!meta copyright="Copyright © 2010 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]]

It is possible to run Hurd stuff on top of another system instead of on Mach.
One obvious variant is emulation ([[hurd/running/QEMU]], for example), but
doing that does not really integratable the Hurd guest into the host system.
There is also a more direct way, more powerful, but it also has certain
requirements to do it effectively:

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.
    <marcusb> silver_hook: it's surprising how few systems *have* transferable
      rights, though!
    <marcusb> silver_hook: usually it is added as an afterthought
    <marcusb> and comes with restriction
    <youpi> marcusb: there's SCM_RIGHTS to transfer fds, which is quite often
      available
    <marcusb> youpi: yes, I know this as "fdpassing"
    <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
    <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> 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
    <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
      started it

([[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

(Continue: [[benefits]].)