diff options
| -rw-r--r-- | hurd/translator/procfs/jkoenig/discussion.mdwn | 18 | ||||
| -rw-r--r-- | open_issues/gnumach_vm_map_entry_forward_merging.mdwn | 11 | ||||
| -rw-r--r-- | open_issues/libpthread_dlopen.mdwn | 36 |
3 files changed, 65 insertions, 0 deletions
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index b66af7de..64e3776e 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -166,3 +166,21 @@ IRC, freenode, #hurd, 2011-03-28 mentoring the previous procfs implementation <antrik> (though I never got around to look at his buggy code...) <jkoenig> ok + +IRC, freenode, #hurd, 2011-07-22 + + <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux? + <jkoenig> pinotree, it reveals information which, while not that sensitive, + would not be available to users through the normal proc interface. + <jkoenig> (it's available through the ps command which is setuid root) + <jkoenig> we discussed at some point making it 644, IIRC. + <pinotree> hm, then why is it not a problem on eg linux? + <jkoenig> (btw you can change it with the -s option.) + <jkoenig> pinotree, it's not a problem because the information is not that + sensitive, but when rewriting procfs I preferred to play it self and + consider it's not procfs' job to decide what is sensitive or not. + <jkoenig> IIRC it's not sensitive but you need the task port to query it. + <jkoenig> like, thread times or something. + <pinotree> status is 644 though + <jkoenig> but status contains information which anyone can ask to the proc + server anyway, I think. diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn index b2b20c5b..f1c8bd6e 100644 --- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn +++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn @@ -171,6 +171,17 @@ License|/fdl]]."]]"""]] entries) +# IRC, freenode, #hurd, 2011-07-21 + + <braunr> tschwinge: you may remove the forward map entry merging issue :/ + <pinotree> what did you discover? + <braunr> tschwinge: it's actually much more complicated than i thought, and + needs major changes in the vm, and about the way anonymous memory is + handled + <braunr> from what i could see, part of the problem still exists in freebsd + <braunr> for the same reasons (shadow objects being one of them) + + # Procedure * Analyze. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn new file mode 100644 index 00000000..f60c81a4 --- /dev/null +++ b/open_issues/libpthread_dlopen.mdwn @@ -0,0 +1,36 @@ +[[!meta copyright="Copyright © 2011 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_libpthread]] + +IRC, OFTC, #debian-hurd, 2011-07-21. + + <youpi> there's one known issue with pthreads + <youpi> you can't dlopen() it + <youpi> which also means you can't dlopen() a module which depends on it if + the main application hasn't used -lpthread already + <youpi> (so as to get libpthread initialized early, not at the dlopen() + call) + <lucas> I get this while building simgrid: + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + /usr/bin/cmake -E create_symlink + /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so + /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so + <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console && + lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua + <lucas> lua: + /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68: + __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed. + <lucas> Aborted (core dumped) + <youpi> that's it, yes + <youpi> (or at least it has the same symptoms) + <lucas> it would need fixing in lua, not in SG, then, right? + <youpi> yes + <lucas> ok, thanks |