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
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
[[!meta copyright="Copyright © 2011, 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_documentation]]
[[!toc]]
# Mach initiating RPCs to userspace tasks
## IRC, freenode, #hurd, 2011-06-11
<antrik> I don't think we have a precendence case of Mach initiating RPCs
to userspace tasks
<braunr> well mach regularly sends RPCs to external pagers
<antrik> hm, right
<antrik> anyways, the ds_ in device.defs is for use *inside* Mach, not for
the userspace interface
<braunr> what makes you think so ?
<antrik> several things
<antrik> not least the fact that without zhengda's modifications, the
device handling never calls out to userspace for all I know
<braunr> hm, it does
<braunr> for async I/O
<braunr> when the kernel has finished its I/O, it calls
ds_device_read_reply/ds_device_write_reply
<antrik> I see
<antrik> I never quite understood the _reply stuff
<braunr> although i wonder how mig is supposed to forge those names
<antrik> braunr: it isn't
<antrik> braunr: there is a separate device_reply.defs
<antrik> braunr: and it sets a *userprefix* of ds_
<antrik> rather than a serverprefix
<braunr> i saw, yes
<braunr> ah right
<antrik> so ds still refers to the in-Mach device server, not anything
userspace
<braunr> so this is where the patch is supposed to introduce the
device_intr_notify RPC
<antrik> or at least that's my understanding...
<braunr> no, it doesn't refer to in-mach servers
<braunr> it really forges the right rpcs to be called by mach
<antrik> the definition of "RPC" is rather unclear here
<braunr> why ?
<braunr> mach has its own mach_msg() call for kernel-to-user messaging
<antrik> yes, but this is used only to send the reply message for the RPC
earlier initiated by userspace AIUI
<antrik> it doesn't look like there is any special RPC for async I/O
<braunr> yes, because this is the only use case they had
<braunr> hence the name "reply"
<braunr> intr_notify isn't a reply, but it uses the same mechanism
<braunr> these are declared as simpleroutine
<antrik> sure. but the fact that it isn't a reply message, but rather
initiates a new RPC, changes things from MiG point of view I believe
<antrik> right, as there is no reply to the reply :-)
<braunr> :)
<braunr> a simpleroutine is how to turn an rpc into a simple ipc
<antrik> I know
<antrik> so in _reply, we pretend that the reply is actually a new RPC,
with server and client roles reversed, and no reply
<antrik> (this is actually rather kludgy... apparently MIG has no real
notion of async replies)
<braunr> i don't understand what you mean
<braunr> simpleroutine is the explicit solution for async replies
<braunr> as stated in
http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps
<braunr> it's not a new rpc with roles reversed
<braunr> it's not a reply either
<antrik> it might be an explicit solution for that, but it still seems
kludgy :-)
<braunr> i don't see why :/
<braunr> would you have expected something like an option to create both
sync and async versions ?
<antrik> because it requires an extra .defs file
<antrik> yes
<braunr> ok
<braunr> well this seems cumbersome to me :)
<braunr> i prefer the simpleroutine approach
<braunr> but i agree this seems odd since mach has a high level ipc api
<antrik> anyways, my point is that the ds_ in device_reply.defs still
refers to the Mach side of things
<braunr> npnth: which package fails to build ?
<antrik> though a userspace process that actually handles the replies in an
async fashion will of course need some kind of device server too, just
like the DDE stuff...
<antrik> though naming it ds_ is confusing IMHO, because of the name clash
with the device server in Mach
<braunr> hm again, i fail to see why
<braunr> ds_ just means device_server
<braunr> and as most things in mach, it can be in kernel or not
<braunr> i mean, this is an interface prefix, i don't refer to an actual
single instance of a "device server" out there
<antrik> oh, right... DDE implements the Mach device protocol, so it *does*
do the ds_ part... but that makes the interrupt notification stuff even
more confusing
<braunr> hm
<braunr> because it provides a ds_device_intr_notify() which will never be
used, just to completely implement the interface ?
<antrik> yeah, that's what I suspect...
<braunr> sounds likely
<antrik> the device interface actually has two parts: one for "generic"
RPCs on the master device port, and one for device-specific RPCs. DDE
implements the latter, and uses the former...
<antrik> they live in separate places though I think: the individual device
RPCs are implemented in libmachdev, while the intr_ stuff is used in
libddekit probably
<braunr> it would be hairy to build otherwise
<antrik> so we *really* need to know what component npnth gets the error
with
<antrik> braunr: nah, not really. that's why we always have a separate
prefix for the server routines in Hurd RPCs
<braunr> right, i really need to read about mig again
<antrik> it's pretty normal for a translator to both implement and use an
interface
# `MACH_SEND_INTERRUPT`/`MACH_RCV_INTERRUPT`
[[!tag open_issue_glibc open_issue_gnumach]]
## IRC, freenode, #hurd, 2013-03-22
<braunr> i'm also testing glibc packages on darnassus with a patch that
removes the MACH_{SEND,RCV}_INTERRUPT options from mach_msg calls to
avoid taking the slow path because of them
<braunr> if i got it right, almost every mach_msg call doesn't use any of
these options, except for select
<braunr> it could slightly improve that, i'm not sure
<youpi> but don't we need that to get EINTR ?
<braunr> the options are purely userspace
<braunr> i'll upload the patch
<braunr>
http://www.sceen.net/~rbraun/0001-Mask-options-implemented-by-the-userspace-side-of-ma.patch
<youpi> ah, ok, you mean userspace already implements what we need
## IRC, freenode, #hurd, 2013-04-23
<braunr> i couldn't measure any difference with the glibc patch that
removes the mach_msg interrupt related flags
<braunr> which isn't very surprising as it only concerns select as far as i
can tell
|
