From 6f9c0342f33f52a2bda98d3709fbefd678bd46d9 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 13 May 2012 06:06:11 +0200 Subject: IRC. --- hurd/translator/procfs/jkoenig/discussion.mdwn | 61 +++++++++++++++++++++++++- 1 file changed, 60 insertions(+), 1 deletion(-) (limited to 'hurd/translator/procfs') diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..e7fdf46e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011, 2012 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 @@ -218,3 +219,61 @@ Needed by glibc's `pldd` tool (commit # `/proc/self/exe` [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]] + + +# `/proc/[PID]/fd/` + +## IRC, freenode, #hurd, 2012-04-24 + + braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + wait, I mean /proc/self... for /proc/*/fd it's even more + straighforward -- we might even have a magic lookup for that already + i guess the ideal thing would be implement that fd logic in + libps + pinotree: nope. it doesn't need to ask proc (or any other server) + at all. it's local information. that's what we have the magic lookups for + one option we were considering at some point would be using the + object migration mechanism, so the actual handling would still happen + client-side, but the server could supply the code doing it. this would + allow servers to add arbitrary magic lookup methods without any global + modifications... but has other downsides :-) + youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + see my mail + I don't think there is an interface for that + processes handle fds themselves + so libps would have to peek in there + and I don't remember having seen any code like that + 10:17:17< antrik> wait, I mean /proc/self... for /proc/*/fd it's + even more straighforward -- we might even have a magic lookup for that + already + pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + for /proc/self/fd we have a magic lookup + for /proc/pid/fd, I don't think we have + magic lookup* + magic lookup == RPC? + magic lookup is a kind of answer to the lookup RPC + that basically says "it's somewhere else, see there" + the magic FD lookup tells the process "it's your FD number x" + which works for /proc/self/fd, but not /proc/pid/fd + youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + `msgport' should have --get-fd, actually + civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + so we can get a port on the fd + but then how to know what it is? + youpi: ah, you mean for the /proc/X/fd symlinks? + good question + it's not designed to be mapped back to names, indeed :-) + youpi: yeah, I realized myself that only /proc/self/fd is trivial + BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + not real symlinks + it's very weird for example for fd connected to files that have + been unlinked. it looks like a broken symlink, but when dereferencing + (e.g. with cp), you get the actual file contents... -- cgit v1.2.3