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
125
126
127
128
129
130
131
132
133
134
135
|
[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 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_glibc open_issue_hurd]]
[[!toc]]
# bug-hurd discussion.
# IRC, freenode, #hurd, 2010-08-12
<jkoenig> Looking at hurd.git, shouldn't {hurd,include}/Makefile's "all"
target do something, and shouldn't pretty much everything depend on them?
As it stands it seems that the system headers are used and the
potentially newer ones never get built, except maybe on "install" (which
is seemingly never called from the top-level Makefile)
<jkoenig> I would fix it, but something tells me that maybe it's a feature
:-)
<antrik> jkoenig: the headers are provided by glibc, along with the stubs
<jkoenig> antrik, you mean, even those built from the .defs files in hurd/
?
<antrik> yes
<jkoenig> oh, ok then.
<antrik> as glibc provides the stubs (in libhurduser), the headers also
have to come from there, or they would get out of sync
<jkoenig> hmm, shouldn't glibc also provide /usr/share/msgids/hurd.msgids,
then?
<antrik> jkoenig: not necessarily. the msgids describe what the servers
actually understand. if the stubs are missing from libhurduser, that's no
reason to leave out the msgids...
<jkoenig> ok this makes sense
# IRC, OFTC, #debian-hurd, 2011-09-29
<tschwinge> pinotree: I don't like their existence. IMO (but I haven't
researched this in very much detail), every user of RPC stubs should
generated them for themselves (and glibc should directly include the
stubs it uses internally).
<pinotree> sounds fair
<pinotree> maybe they could be moved from glibc to hurd?
<tschwinge> pinotree: Yeah; someone needs to research why we have them (or
if it's only convenience), and whether we want to keep them.
<pinotree> you could move them to hurd, leaving them unaltered, so binary
compatibility with eventual 3rd party users is not broken
<pinotree> but those using them, other than hurd itself, won't compile
anymore, so you fix them progressively
# IRC, freenode, #hurd, 2011-11-16
<braunr> is the mach_debug interface packaged in debian ?
<antrik> what mach_debug interface?
<braunr> include/include/mach_debug/mach_debug.defs in gnumach
<braunr> include/mach_debug/mach_debug.defs in gnumach
<antrik> what exactly is supposed to be packaged there?
<braunr> i'm talking about the host_*_info client code
<antrik> braunr: you mean MIG-generated stubs?
<braunr> antrik: yes
<braunr> i wrote a tiny slabinfo tool, and rpctrace doesn't show the
host_slab_info call
<braunr> do you happen to know why ?
<antrik> braunr: doesn't show it at all, or just doesn't translate?
<braunr> antrik: doesn't at all, the msgids file contains what's needed to
translate
<braunr> btw, i was able to build the libc0.3 packages with a kernel using
the slab allocator today, while monitoring it with the aforementioned
slabinfo tool, everything went smoothly
<antrik> great :-)
<braunr> i'll probably add a /proc/slabinfo entry some day
<braunr> and considering the current state of our beloved kernel, i'm
wondering why host_*_info rpcs are considered debugging calls
<braunr> imo, they should always be included by default
<braunr> and part of the standard mach interface
<braunr> (if the rpc is missing, an error is simply returned)
<antrik> I guess that's been inherited from original Mach
<antrik> so you think the stubs should be provided by libmachuser?
<braunr> i'm not sure
<antrik> actually, it's a bit arguable. if interfaces are not needed by
libc itself, it isn't really necessary to build them as part of the libc
build...
<braunr> i don't know the complete list of potential places for such calls
<antrik> OTOH, as any updates will happen in sync with other Mach updates,
it makes sense to keep them in one place, to reduce transition pain
<braunr> and i didn't want to imply they should be part of libc
<braunr> on the contrary, libmachuser seems right
<antrik> libmachuser is part of libc
<braunr> ah
<braunr> :)
<braunr> why so ?
<antrik> well, for one, libc needs the Mach (and Hurd) stubs itself
<antrik> also, it's traditionally the role of libc to provide the call
wrappers for syscalls... so it makes some sense
<braunr> sure, but why doesn't it depend on an external libmachuser instead
of embedding it ?
<braunr> right
<antrik> now that's a good question... no idea TBH :-)
# IRC, freenode, #hurd, 2012-07-23
<pinotree> aren't libmachuser and libhurduser supposed to be slowly faded
out?
<tschwinge> pinotree: That discussion has not yet come to a conclusion, I
think. (I'd say: yes.)
# IRC, freenode, #hurd, 2012-12-17
<pinotree> what was the idea about using the rpc stubs currently in
libmachuser and libhurduser? should they be linked to explicitly, or
assume libc brings them?
<braunr> pinotree: libc should bring them
# IRC, freenode, #hurd, 2013-02-25
<braunr> we should also discuss the mach_debug interface some day
<braunr> it's not exported by libc, but the kernel provides it
<braunr> slabinfo depends on it, and i'd like to include it in the hurd
<braunr> but i don't know what kind of security problems giving access to
mach_debug RPCs would create
<braunr> (imo, the mach_debug interface should be adjusted to be used with
privileged ports only)
<braunr> (well, maybe not all mach_debug RPCs)
|
