summaryrefslogtreecommitdiff
path: root/open_issues/anatomy_of_a_hurd_system.mdwn
blob: 13599e1959289af08e23736b036aa75501679e86 (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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
[[!meta copyright="Copyright © 2011 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]]."]]"""]]

[[!taglink open_issue_documentation]]

A bunch of this should also be covered in other (introductionary) material,
like Bushnell's Hurd paper.  All this should be unfied and streamlined.

IRC, freenode, #hurd, 2011-03-08:

    <foocraft> I've a question on what are the "units" in the hurd project, if
      you were to divide them into units if they aren't, and what are the
      dependency relations between those units(roughly, nothing too pedantic
      for now)
    <antrik> there is GNU Mach (the microkernel); there are the server
      libraries in the Hurd package; there are the actual servers in the same;
      and there is the POSIX implementation layer in glibc
    <antrik> relations are a bit tricky
    <antrik> Mach is the base layer which implements IPC and memory management
    <foocraft> hmm I'll probably allocate time for dependency graph generation,
      in the worst case
    <antrik> on top of this, the Hurd servers, using the server libraries,
      implement various aspects of the system functionality
    <antrik> client programs use libc calls to use the servers
    <antrik> (servers also use libc to communicate with other servers and/or
      Mach though)
    <foocraft> so every server depends solely on mach, and no other server?
    <foocraft> s/mach/mach and/or libc/
    <antrik> I think these things should be pretty clear one you are somewhat
      familiar with the Hurd architecture... nothing really tricky there
    <antrik> no
    <antrik> servers often depend on other servers for certain functionality

---

IRC, freenode, #hurd, 2011-03-12:

    <dEhiN> when mach first starts up, does it have some basic i/o or fs
      functionality built into it to start up the initial hurd translators?
    <antrik> I/O is presently completely in Mach
    <antrik> filesystems are in userspace
    <antrik> the root filesystem and exec server are loaded by grub
    <dEhiN> o I see
    <dEhiN> so in order to start hurd, you would have to start mach and
      simultaneously start the root filesystem and exec server?
    <antrik> not exactly
    <antrik> GRUB loads all three, and then starts Mach. Mach in turn starts
      the servers according to the multiboot information passed from GRUB
    <dEhiN> ok, so does GRUB load them into ram?
    <dEhiN> I'm trying to figure out in my mind how hurd is initially started
      up from a low-level pov
    <antrik> yes, as I said, GRUB loads them
    <dEhiN> ok, thanks antrik...I'm new to the idea of microkernels, but a
      veteran of monolithic kernels
    <dEhiN> although I just learned that windows nt is a hybrid kernel which I
      never knew!
    <rm> note there's a /hurd/ext2fs.static
    <rm> I belive that's what is used initially... right?
    <antrik> yes
    <antrik> loading the shared libraries in addition to the actual server
      would be unweildy
    <antrik> so the root FS server is linked statically instead
    <dEhiN> what does the root FS server do?
    <antrik> well, it serves the root FS ;-)
    <antrik> it also does some bootstrapping work during startup, to bring the
      rest of the system up

---

Provide a cross-linked sources documentation, including generated files, like
RPC stubs.

  * <http://www.gnu.org/software/global/>

---

[[Hurd_101]].

---

More stuff like [[hurd/IO_path]].

---

IRC, freenode, #hurd, 2011-10-18:

    <frhodes> what happens @ boot. and which translators are started in what
      order?
    <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts
      ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs
      init. from there on, it's just standard UNIX stuff

---

IRC, OFTC, #debian-hurd, 2011-11-02:

    <sekon_> is __dir_lookup a RPC ??
    <sekon_> where can i find the source of __dir_lookup ??
    <sekon_> grepping most gives out rvalue assignments 
    <sekon_> -assignments 
    <sekon_> but in hurs/fs.h it is used as a function ??
    <pinotree> it should be the mig-generated function for that rpc
    <sekon_> how do i know how its implemented ??
    <sekon_> is there any way to delve deeprer into mig-generated functions 
    <tschwinge> sekon_: The MIG-generated stuff will either be found in the
      package's build directory (if it's building it for themselves), or in the
      glibc build directory (libhurduser, libmachuser; which are all the
      available user RPC stubs).
    <tschwinge> sekon_: The implementation can be found in the various Hurd
      servers/libraries.
    <tschwinge> sekon_: For example, [hurd]/libdiskfs/dir-lookup.c.
    <tschwinge> sekon_: What MIG does is provide a function call interface for
      these ``functions'', and the Mach microkernel then dispatches the
      invocation to the corresponding server, for example a /hurd/ext2fs file
      system (via libdiskfs).
    <tschwinge> sekon_: This may help a bit:
      http://www.gnu.org/software/hurd/hurd/hurd_hacking_guide.html