summaryrefslogtreecommitdiff
path: root/open_issues/translate_fd_or_port_to_file_name.mdwn
blob: 01ab3a787a5ae37d85a153a72da5970398752b92 (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
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
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
[[!meta copyright="Copyright © 2010, 2011, 2013, 2014, 2015 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]]


# [[glibc]]'s `fd_to_filename`


# IRC, freenode, #hurd, June (?) 2010

    <pochu> is there a way (POSIX or Hurdish) to get the corresponding file
      name for a fd or a hurd port?
    <marcusb> there is a way
    <pochu> marcusb: which one would that be?
    <marcusb> I forgot
    <marcusb> there is an implementation in libc
    <marcusb> realpath has a similar job
    <marcusb> but that's not what I mean
    <marcusb> pochu: maybe I am misremembering.  But it was something where you
      keep looking up .. and list that directory, looking for the node with the
      ID of the node you had .. for
    <marcusb> maybe it works only for directories
    <marcusb> yeah
    <marcusb> pochu: check the getcwd() implementation of libc
    <marcusb> sysdeps/mach/hurd/getcwd.c
    <marcusb> _hurd_canonicalize_directory_name_internal 
    * pochu looks
    <pochu> marcusb: interesting
    <pochu> though that is for dirs, and doesn't seem to be extensible to
      files, as you cannot lookup for ".." under a file
    <marcusb> right
    <pochu> oh you already said that :)
    <marcusb> actually, I am not sure that's correct
    <marcusb> it's probably correct, but there is no reason why looking .. up
      on a file couldn't return the directory it's contianed in
    <pochu> I don't know the interfaces or the Hurd internals very well yet,
      but it would look strange to me if you could do that
    <marcusb> the hurd is strange
    <pochu> it sounds like if you could `ls getcwd.c/..` to get
      sysdeps/mach/hurd/ :-)
    <marcusb> yep
    <pochu> ok. interesting
    <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you?
    <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip
    <marcusb> there you go
    <marcusb> or the other way round: would you be surprised if "cat somedir"
      would work?
    <pochu> I think so. if it did, what would it do?
    <marcusb> originally, cat dir would list the directory content!
    <marcusb> in the old unix times
    <pochu> I was surprised the first time I typed `vi somedir` by accident
    <marcusb> and some early BSDs 
    * pochu feels young :-)
    <marcusb> he don't worry, I didn't see those times either
    <marcusb> technically, files and directories are implemented in the same
      way in the hurd, they both are objects implementing the fs.defs interface
    <marcusb> which combines file and directory operations
    <marcusb> of course, files and directories implement those functions
      differently
    <antrik> marcusb: do you know why this behavior (cat on directories) was
      changed?


## IRC, freenode, #hurd, 2013-03-07

    * pinotree ponders about sending as RFC his patch for /proc/$pid/maps
    <tschwinge> Including a scheme for providing the names of mapped files?
      ;-D
    <braunr> that would be really great indeed
    <tschwinge> I have not yet researched how Linux does this.  Perhaps store
      the filename used for first opening a file as a string somewhere?
    <pinotree> tschwinge: eh, indeed that's lacking in my patch
    <braunr> i'm not sure we should aim at doing it the same way
    <youpi> I was wondering about having interfaces for naming tasks, threads,
      objects
    <youpi> that'd be useful for debugging in general
    <braunr> yes
    <braunr> i don't think we need to take namespaces into account
    <braunr> a simple name or path should be quite enough
    <tschwinge> Agreed.  "Just something!"
    <tschwinge> So, a Java toString() method for ports.
    <tschwinge> ;-)
    <braunr> yes
    <tschwinge> Oh, and could this also work recursively?  The ext2fs instance
      on /home asks its parent fs about its own path -- can it do that?  (And
      then cache that, most likely?)  Would one get rooted filesnames that way?
    <braunr> i really don't think we should link it to the VFS
    <braunr> it should merely be a name for debugging
    <youpi> yep, same for me
    <youpi> I'd say it's the linker's task of just setting a sane name
    <braunr> first, keeping it isolated prevents increasing complexity
    <braunr> next, it doesn't reduce performance
    <tschwinge> youpi: Linker?
    <tschwinge> braunr: Ack.
    <braunr> yes, ld is the one creating the mappings
    <youpi> tschwinge: the one that loads libraries
    <tschwinge> Ah, for /proc/*/maps, right.  I've been thinking more globally.


## task_get_name, task_set_name RPCs

The following needs to be updated now that
[[microkernel/mach/gnumach/interface/task_set_name]] has been implemented.

[[!message-id "518AA5B0.6030409@verizon.net"]]


## IRC, freenode, #hurd, 2013-05-10

    <youpi> tschwinge's suggestion to put names on ports instead of tasks would
      be useful too
    <braunr> do you get task ports as easily as you get tasks in kdb ?
    <youpi> there is task->itk_self & such
    <youpi> or itk_space
    <youpi> I don't remember which one is used by userspace
    <braunr> i mean
    <braunr> when you use the debugger, can you easily find its ports ?
    <braunr> the task ports i mean
    <braunr> or thread ports or whatever
    <youpi> once you have a task, it's a matter of getting the itk_self port
    <youpi> s/port/field member/
    <braunr> so the debugger provides you with the addresses of the structs
    <braunr> right ?
    <youpi> yes, that's what we have already
    <braunr> then ok
    <braunr> bddebian: do that :p
    <braunr> hehe
    <youpi> see show all thread
    <braunr> (haven't used kdb in a long time)
    <bddebian> So, adding a name to ports like I did with tasks?
    <braunr> remove what you did for tasks
    <braunr> move it to ports
    <braunr> it's very similar
    <braunr> but hm
    <braunr> i'm not sure where the RPC would be
    <braunr> this RPC would exist for *all* ports
    <braunr> or only for kernel objects if added to gnumach.defs
    <youpi> it's just about moving the char array field to another structure
    <youpi> and plugging that
    <bddebian> But mach_task_self is a syscal, it looks like itk_self is just a
      pointer to an ipc_port ?
    <braunr> so ?
    <braunr> you take that pointer and you get the port
    <braunr> just like vm_map gets a struct vm_map from a task
    <bddebian> So I am just adding ipc_port_name to the ipc_port struct in this
      case?
    <braunr> yes
    <braunr> actually
    <braunr> don't do anything just yet
    <braunr> we need to sort a few details out first
    <braunr> see bug-hurd


## IRC, freenode, #hurd, 2013-12-05

    <teythoon> braunr: no more room for vm_map_find_entry in 80220a40
    <teythoon> 80220a40 <- is that a task ?
    <braunr> or a vm_map, not sure
    <braunr> probably a vm_map
    <teythoon> hm
    <teythoon> let's fix this kind of reporting
    <braunr> :)
    <teythoon> let one process register for kernel log messages
    <teythoon> make a rich interface, say klog_thread and friends
    <teythoon> a userspace process gets the port name, looks it up in proc,
      logs nicely to syslog
    <teythoon> if noone registered for this notifications, fall back to the old
      reporting
    <braunr> i tend to think using internal names is probably better
    <teythoon> how would i use them to see wich process caused the issue ?
    <braunr> you give the name of the task
    <braunr> (which means tasks have names, yes)
    <teythoon> ok
    <braunr> the reason is that reporting is often used for debugging
    <braunr> and debugging usually means there is a bug
    <braunr> if the bug prevents from reporting, it's not very useful
    <braunr> and we're talking about the kernel here, the low level stuff
    <teythoon> incidentally, i got myself a stuck process
    <teythoon> ah, got it killed
    <teythoon> braunr: so you propose to add a task rpc to set a name ?
    <braunr> i don't want to push such things
    <braunr> which is why this hasn't been done until now
    <braunr> but that's what i'd do in x15, yes
    <teythoon> y not ?
    <braunr> and instead of a process registered to gather kernel messages, i'd
      use a dmesg-like interface, where the kernel manages its message buffer
      itself
    <braunr> i didn't feel the need to
    <braunr> the tools i've had until now were sufficient
    <braunr> don't forget you still need to fix mtab :p
    <braunr> or is it done ?
    <teythoon> i sometimes see tasks deallocating invalid ports
    <teythoon> no
    <teythoon> there is an un-acked patche series on the list
    <braunr> ok
    <teythoon> so, i want to identify which process caused it
    <teythoon> is that possible right now ?
    <braunr> not easily, no
    <teythoon> so that's a valid use case
    <braunr> it is
    <teythoon> good
    <teythoon> :)
    <teythoon> so proc would register a string describing each task and mach
      would use this for printing nicer messages ?
    <braunr> for example, yes
    <braunr> one problem with that approach is that it doesn't fit well with
      subhurds
    <teythoon> *bingbingbing
    <braunr> but i personally wouldn't care much, they're kernel messages
    <braunr> in the future, we could make mach more a hypervisor, and register
      names for each domains
    <teythoon> yet unanswered proposal about hierachical proc servers on the
      list...
    <teythoon> that'd also fix subhurds, so that the parents processes won't
      appear in the subhurd
    <teythoon> making it sandboxier
    <teythoon> and killall5 couldn't slaughter the host system if the subhurd
      shuts down with sysvinit


## IRC, freenode, #hurd, 2014-01-20

    <teythoon> i wonder if it would not be best to add a description to mach
      tasks
    <braunr> i think it would
    <teythoon> to aid fixing these kind of issues
    <braunr> in x15, i actually add descriptions (names) to all kernel objects
    <teythoon> that's probably a good idea, yes
    <braunr> well, not all, but many


## IRC, OFTC, #debian-hurd, 2014-02-05

    <teythoon> youpi: about that patch implementing task_set_name, may i merge
      the amended version ?
    <youpi> yes


# IRC, freenode, #hurd, 2011-07-13

A related issue:

    <braunr> rbraun@nordrassil:~$ vminfo $$ | wc -l
    <braunr> 1039
    <braunr> any idea why a shell would consume more than 1039 map entries ?
    <braunr> (well, not more actually)
    <braunr> even the kernel and ext2fs have around 100
    <braunr> (the kernel has actually only 23, which is very good and expected)
    <tschwinge> braunr: I agree that having some sort of debugging information
      for memory objects et al. would be quite hand.  To see where they're
      coming from, etc.
    <braunr> tschwinge: this would require naming objects at the mach level
    <braunr> e.g. when creating an object
    <braunr> giving it the path of a file for example
    <tschwinge> braunr: I have recently seen something (due to youpi fixing a
      bug) that bash is doing its own memory management.  Perhaps all these are
      such regions?
    <tschwinge> braunr: For example, yes.
    <braunr> what ?
    <braunr> ?!
    <tschwinge> braunr:
      http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html
    <braunr> i see

Also see email thread starting at [[!message-id
"20110714082216.GA8335@sceen.net"]].

Justus: Once [[!message-id desc="these patches"
"1375178364-19917-4-git-send-email-4winter@informatik.uni-hamburg.de"]] are
merged, there will be a way to map from ports to file names, at least for
libdiskfs and libnetfs, one would only have to make this information available
somehow.