diff options
Diffstat (limited to 'open_issues/translate_fd_or_port_to_file_name.mdwn')
| -rw-r--r-- | open_issues/translate_fd_or_port_to_file_name.mdwn | 51 |
1 files changed, 51 insertions, 0 deletions
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn index 0d786d2a..0d6a460c 100644 --- a/open_issues/translate_fd_or_port_to_file_name.mdwn +++ b/open_issues/translate_fd_or_port_to_file_name.mdwn @@ -105,6 +105,57 @@ License|/fdl]]."]]"""]] <tschwinge> Ah, for /proc/*/maps, right. I've been thinking more globally. +## task_get_name, task_set_name RPCs + +[[!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, 2011-07-13 A related issue: |