summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2011-07-22 09:41:11 +0200
committerThomas Schwinge <tschwinge@gnu.org>2011-07-22 09:41:11 +0200
commit088ca85671518ac9033904dae6444d7d532586d4 (patch)
treea0fb08a657091a42cf4bc2ccdf72e0892eeed646
parentd0d1e7f069a370003b1a889b9c6f61822bba44fd (diff)
IRC.
-rw-r--r--hurd/translator/procfs/jkoenig/discussion.mdwn18
-rw-r--r--open_issues/gnumach_vm_map_entry_forward_merging.mdwn11
-rw-r--r--open_issues/libpthread_dlopen.mdwn36
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