diff options
Diffstat (limited to 'hurd/translator/procfs/jkoenig')
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 114 |
1 files changed, 111 insertions, 3 deletions
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 339fab50..182b438b 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 @@ -67,7 +68,7 @@ IRC, #hurd, around October 2010 owner, but always with root group -# `/proc/$pid/stat` being 400 and not 444, and some more +# `/proc/[PID]/stat` being 400 and not 444, and some more IRC, freenode, #hurd, 2011-03-27 @@ -186,7 +187,7 @@ IRC, freenode, #hurd, 2011-07-22 server anyway, I think. -# `/proc/mounts`, `/proc/$pid/mounts` +# `/proc/mounts`, `/proc/[PID]/mounts` IRC, freenode, #hurd, 2011-07-25 @@ -218,3 +219,110 @@ 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 + + <antrik> braunr: /proc/*/fd can be implemented in several ways. none of + them would require undue centralisation + <antrik> braunr: the easiest would be adding one more type of magic lookup + to the existing magic lookup mechanism + <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> i guess the ideal thing would be implement that fd logic in + libps + <antrik> 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 + <antrik> 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 :-) + <gnu_srs> youpi: How much info for /proc/*/fd is possible to get from + libps? Re: d-h@ + <youpi> see my mail + <youpi> I don't think there is an interface for that + <youpi> processes handle fds themselves + <youpi> so libps would have to peek in there + <youpi> and I don't remember having seen any code like that + <gnu_srs> 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 + <gnu_srs> pinotree: For me that does not ring a bell on RPCs. Don't know + what magic means,, + <youpi> for /proc/self/fd we have a magic lookup + <youpi> for /proc/pid/fd, I don't think we have + <gnu_srs> magic lookup* + <gnu_srs> magic lookup == RPC? + <youpi> magic lookup is a kind of answer to the lookup RPC + <youpi> that basically says "it's somewhere else, see there" + <youpi> the magic FD lookup tells the process "it's your FD number x" + <youpi> which works for /proc/self/fd, but not /proc/pid/fd + <civodul> youpi, gnu_srs: regarding FDs, there the msg_get_fd RPC that + could be used + <civodul> `msgport' should have --get-fd, actually + <youpi> civodul: I assumed that the reason why msgport doesn't have it is + that it didn't exist + <youpi> so we can get a port on the fd + <youpi> but then how to know what it is? + <civodul> youpi: ah, you mean for the /proc/X/fd symlinks? + <civodul> good question + <civodul> it's not designed to be mapped back to names, indeed :-) + <antrik> youpi: yeah, I realized myself that only /proc/self/fd is trivial + <antrik> BTW, in Linux it's nor real symlinks. it's magic, with some very + strange (but useful in certain situations) semantics + <antrik> not real symlinks + <antrik> 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... + + +# `/proc/[PID]/maps` + +## IRC, OFTC, #debian-hurd, 2012-06-20 + + <pinotree> bdefreese: the two elfutils tests fail because there are no + /proc/$pid/maps files + <pinotree> that code is quite relying on linux features, like locating the + linux kernel executables and their modules, etc + <pinotree> (see eg libdwfl/linux-kernel-modules.c) + <pinotree> refactor elfutils to have the linux parts executed only on linux + :D + <bdefreese> Oh yeah, the maintainer already seems really thrilled about + Hurd.. Did you see + http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662041 ? + <pinotree> kurt is generally helpful with us (= hurd) + <pinotree> most probably there he is complaining that we let elfutils build + with nocheck (ie skipping the test suite run) instead of investigate and + report why the test suite failed + + +# IRC, freenode, #hurd, 2011-06-19 + + <pinotree> jkoenig: procfs question: in process.c, process_lookup_pid, why + is the entries[2].hook line repeated twice? + <jkoenig> pinotree, let me check + <jkoenig> pinotree, it's probably just a mistake, there's no way the second + one has any effect + <pinotree> jkoenig: i see, it looked like you c&p'd that code accidentally + <jkoenig> pinotree, it's probably what happened, yes. + + +# IRC, freenode, #hurd, 2012-06-30 + + <pinotree> btw, what do you think about making jkoening's procfs master the + real master? + <youpi> probably a good idea + <youpi> it does work quite well, except a few pidof hangs + <pinotree> surely better than the old one :) + <youpi> yes :) + + +# `/proc/[PID]/cwd` + +## IRC, freenode, #hurd, 2012-06-30 + + * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying + on "internal" (but exported) glibc functions |