summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2013-03-06 21:52:20 +0100
committerThomas Schwinge <tschwinge@gnu.org>2013-03-06 21:52:20 +0100
commit12c341b917921eb631026ec44a284c4d884e5de6 (patch)
treec7dc37f605152f5fb6e2d67d6460f78496e3de3d /open_issues
parent53e5e4c139e1b239760434d10e74addd0e89593d (diff)
IRC.
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/arm_port.mdwn16
-rw-r--r--open_issues/bash.mdwn16
-rw-r--r--open_issues/clock_gettime.mdwn121
-rw-r--r--open_issues/dde.mdwn85
-rw-r--r--open_issues/gcc/pie.mdwn10
-rw-r--r--open_issues/git-core-2.mdwn52
-rw-r--r--open_issues/git_duplicated_content.mdwn7
-rw-r--r--open_issues/glibc.mdwn270
-rw-r--r--open_issues/gnumach_page_cache_policy.mdwn29
-rw-r--r--open_issues/gnumach_panic_thread_dispatch.mdwn20
-rw-r--r--open_issues/hurd_101.mdwn25
-rw-r--r--open_issues/libmachuser_libhurduser_rpc_stubs.mdwn14
-rw-r--r--open_issues/libpthread.mdwn346
-rw-r--r--open_issues/mach_tasks_memory_usage.mdwn36
-rw-r--r--open_issues/mission_statement.mdwn11
-rw-r--r--open_issues/multithreading.mdwn90
-rw-r--r--open_issues/nice_vs_mach_thread_priorities.mdwn14
-rw-r--r--open_issues/ogi.mdwn31
-rw-r--r--open_issues/packaging_libpthread.mdwn24
-rw-r--r--open_issues/performance/io_system/read-ahead.mdwn429
-rw-r--r--open_issues/pfinet_timers.mdwn17
-rw-r--r--open_issues/pflocal_socket_credentials_for_local_sockets.mdwn26
-rw-r--r--open_issues/ps_SIGSEGV.mdwn17
-rw-r--r--open_issues/rpc_stub_generator.mdwn49
-rw-r--r--open_issues/select.mdwn458
-rw-r--r--open_issues/select_vs_signals.mdwn15
-rw-r--r--open_issues/some_todo_list.mdwn1
-rw-r--r--open_issues/subhurd_vs_proc_server.mdwn54
-rw-r--r--open_issues/syslog.mdwn11
-rw-r--r--open_issues/system_stats.mdwn8
-rw-r--r--open_issues/systemd.mdwn14
-rw-r--r--open_issues/translators_set_up_by_untrusted_users.mdwn229
-rw-r--r--open_issues/virtualization.mdwn2
-rw-r--r--open_issues/virtualization/fakeroot.mdwn17
-rw-r--r--open_issues/virtualization/remap_root_translator.mdwn44
-rw-r--r--open_issues/vm_map_kernel_bug.mdwn19
36 files changed, 2533 insertions, 94 deletions
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
index 65a82d92..8a2a037f 100644
--- a/open_issues/arm_port.mdwn
+++ b/open_issues/arm_port.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -260,3 +260,17 @@ architecture.
<matty3269> Well, I have a ARM gnumach kernel compiled. It just doesn't
run! :)
<braunr> matty3269: good luck :)
+
+
+# IRC, freenode, #hurd, 2013-01-30
+
+ <slpz> Hi, i've read there's an ongoing effort to port GNU Mach to ARM. How
+ is it going?
+ <braunr> not sure where you read that
+ <braunr> but i'm pretty sure it's not started if it exists
+ <slpz> braunr: http://www.gnu.org/software/hurd/open_issues/arm_port.html
+ <braunr> i confirm what i said
+ <slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
+ duplicate efforts.
+ <braunr> little addition: it may have started, but we don't know about it
+
diff --git a/open_issues/bash.mdwn b/open_issues/bash.mdwn
index 47598071..f6b14a08 100644
--- a/open_issues/bash.mdwn
+++ b/open_issues/bash.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013 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
@@ -8,7 +8,8 @@ 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_porting]]
+[[!tag open_issue_glibc open_issue_porting]]
+
# *bash* 4.0 vs. typing `C-c` (*SIGINT*)
@@ -45,3 +46,14 @@ After having noticed that this error doesn't occur if starting *bash* with
bash: start_pipeline: pgrp pipe: (ipc/mig) wrong reply message ID
So, there's something different with stdout in / after the SIGINT handler.
+
+
+# IRC, freenode, #hurd, 2013-01-13
+
+Perhaps completely unrelated to the issue above, perhaps not.
+
+ <tschwinge> bash: xmalloc: ../../../bash/lib/sh/strtrans.c:60: cannot
+ allocate 261 bytes (323584 bytes allocated)
+ <tschwinge> 1.5 GiB RAM were free.
+ <tschwinge> This happened when I did a rever history search (C-r [...]),
+ and then pressed C-c.
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 5345ed6b..83ad81e8 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -23,7 +23,8 @@ applications assume that it is.
What about adding a nanosecond-precision clock, too? --[[tschwinge]]
-IRC, freenode, #hurd, 2011-08-26:
+
+# IRC, freenode, #hurd, 2011-08-26
< pinotree> youpi: thing is: apparently i found a simple way to have a
monotonic clock as mmap-able device inside gnumach
@@ -40,7 +41,8 @@ IRC, freenode, #hurd, 2011-08-26:
< braunr> sure
< youpi> and that's the way I was considering implementing it
-IRC, freenode, #hurd, 2011-09-06:
+
+# IRC, freenode, #hurd, 2011-09-06
<pinotree> yeah, i had a draft of improved idea for also handling
nanoseconds
@@ -69,3 +71,116 @@ IRC, freenode, #hurd, 2011-09-06:
<youpi> yes
<tschwinge> And it will forever be a witness of the evolving of this
map_time interface. :-)
+
+
+# IRC, freenode, #hurd, 2013-02-11
+
+In context of [[select]].
+
+ <pinotree> braunr: would you send for review (and inclusion) your
+ time_data_t addition?
+ <pinotree> this way we could add nanosecs-based utime rpc (and then their
+ implementation in libc)
+ <braunr> pinotree: it's part of the hurd branch
+ <braunr> do you want it sent separately ?
+ <pinotree> yeah
+ <braunr> ok
+ <braunr> let me get it right first :)
+ <pinotree> sure :)
+
+
+## IRC, freenode, #hurd, 2013-02-12
+
+ <braunr> pinotree:
+ http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout_pthread_v2&id=6ec50e62d9792c803d00cbff1cab2c0b3675690a
+ <pinotree> uh nice
+ <pinotree> will need two small inline functions to convert time_data_t <->
+ timespec, but that's it
+ <braunr> hm right
+ <braunr> i could have thought about it
+ <braunr> but i'll leave it for another patch :p
+ <pinotree> oh sure, no hurry
+
+
+## IRC, freenode, #hurd, 2013-02-19
+
+ <youpi> braunr: about time_data_t, I get it's needed that it be an array
+ <youpi> so it can be passed by reference, not by value?
+ <braunr> by address, yes
+ <braunr> that's the difference between array and struct
+
+
+## IRC, freenode, #hurd, 2013-02-25
+
+ <youpi> braunr: why did you want to see time_data passed as pointer, not as
+ struct?
+ <braunr> to microoptimize
+ <braunr> the struct is 2 64-bit integers
+ <youpi> well, we already pass structs along in a few cases,
+ e.g. io_statbuf_t, rusage_t, etc.
+ <youpi> be it written t[0].sec or t->sec, it seems odd
+ <youpi> copying 2 64bit integers is not much compared to the potential for
+ bugs here
+ <braunr> bugs ?
+ <youpi> yes, as in trying to access t[1], passing a wrong pointer, etc.
+ <youpi> or the reader frowning on "why is this case different than the
+ others?"
+ <braunr> well, i'm already usually frowning when i see what mig does ..
+ <youpi> right
+ <youpi> on the plus side, it's only the client side, i.e. mostly glibc,
+ which sees the t[0]
+ <braunr> and the practice established by my patch is to convert to struct
+ timespec as soon as possible
+ <braunr> the direct use of this type is therefore limited
+ <youpi> could we define time_data_t as a struct time_data * instead of
+ struct time_data[1] ?
+ <youpi> (in the.h)
+ <youpi> that would make more sense to define a struct time_data, and pass a
+ pointer to it
+ <braunr> i'm not sure
+ <braunr> the mach server writing guide was very clear about array implying
+ a C array too
+ <braunr> and i remember having compilation problems before doing that
+ <braunr> but i don't remember their nature exactly
+ <youpi> I'm not sure to understand what you said about converting to struct
+ timespec
+ <youpi> what makes it not possible now?
+ <youpi> and what is the relation with being an array or a pointer?
+ <braunr> concerning struct timespec, what i mean is that the functions
+ called by the mig stub code directly convert time_data_t to a struct
+ timespec (which is the real type used throughout the hurd code)
+ <braunr> about the rest, i'm not sure, i'd have to try again
+ <braunr> mig just assumes it's an array
+ <youpi> and why not just using struct timespec?
+ <youpi> (for the mig type too)
+ <braunr> my brain can't correctly compute variable sized types in mig
+ definition files
+ <braunr> i wanted something that would remain correct for the 64-bit port
+ <youpi> ah, you mean because tv_nsec is a long, which will not be the same
+ type?
+ <braunr> and tv_sec being a time_t (thus a long too)
+ <youpi> but we have the same issue e.g. for the rusage structure, don't we?
+ <braunr> yes
+ <youpi> so we'll have to fix things for that too anyway
+ <braunr> sure
+ <youpi> making a special case will not necessarily help
+ <braunr> but it doesn't mean new interfaces have to be buggy too
+ <youpi> well, using the proper type in the server itself is nicer
+ <youpi> instead of having to convert
+ <braunr> yes
+ <braunr> i'm not exactly sure where to declare struct timespec then
+ <braunr> should it be declared in hurd_types.h, and simply reused by the
+ libc headers ?
+ <youpi> ? AIUI, it's the converse, hurd_types.h uses the struct timespec
+ from libc headers, and defines timespec_t
+ <braunr> ok
+ <youpi> timespec_t being the internal type whose definition gets done right
+ for mig to do the right thing
+ <braunr> yes
+ <braunr> i see
+ <braunr> so, you'd like a struct of integer_t instead of an array of
+ signed64
+ <youpi> for our current 32bit userland yes
+ <braunr> do you want to make the changes yourself or should i add a new
+ branch ?
+ <youpi> and we'll make that a 64bit struct when we have a64bit userland
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 5f6fcf6a..b25e53d7 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -33,7 +33,7 @@ The plan is to use [[libstore_parted]] for accessing partitions.
## IRC, freenode, #hurd, 2012-02-08
-At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
+After the microkernel devroom at [[community/meetings/FOSDEM_2012]]:
<antrik> there was quite some talk about DDE. I learnt that there are newer
versions in Genode and in Minix (as opposed to the DROPS one we are
@@ -109,6 +109,40 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
you want. It uses Linux 2.6.26 usb subsystem.
+## IRC, freenode, #hurd, 2013-02-15
+
+After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
+
+ <pinotree> youpi: speaking of dde, was there any will among other
+ microkernel os developers to eventually develop one single dde (with
+ every team handling the custom glue of the own kernel)?
+ <youpi> well, there is still upstream dde actually
+ <youpi> in dresden
+ <youpi> nothing was really decided or anything (it was a round table, not a
+ workgroup)
+ <youpi> but conversation converged into sharing the DDE maintenance, yes
+ <youpi> and dresden would be the logical central place
+ <youpi> pb is that they don't have the habit of being very open
+ <youpi> http://svn.tudos.org/repos/oc/tudos/trunk/l4/pkg/dde has a recent
+ enough version
+ <youpi> which macsim confirmed having all the latest commits from the
+ internal repository
+ <pinotree> i see
+ <youpi> so it seems a viable solution on the medium term
+ <youpi> the long term might need a real visible open source project
+ <youpi> but we should probably still keep basing on dresden work
+ <youpi> (better take work being done anywhere)
+ <pinotree> well, if the upstream is not really open, microkernel teams
+ could just fork it and all work on it
+ <youpi> that's what I mean
+ <pinotree> should still be a win than everybody maintaining their own dde
+ <youpi> sure
+ <pinotree> ah yes, i was writing and i'm slow at it :)
+ <youpi> but at least we can try to work with dresden
+ <youpi> see how open they could become by just asking :)
+ <pinotree> right
+
+
# IRC, OFTC, #debian-hurd, 2012-02-15
<pinotree> i have no idea how the dde system works
@@ -484,26 +518,17 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
<braunr> *sigh*
-
-# IRC, freenode, #hurd, 2012-08-18
+## IRC, freenode, #hurd, 2012-08-18
<braunr> hum, leaks and potential deadlocks in libddekit/thread.c :/
-# IRC, freenode, #hurd, 2012-08-18
+## IRC, freenode, #hurd, 2012-08-18
<braunr> nice, dde relies on a race to start ..
-# IRC, freenode, #hurd, 2012-08-18
-
- <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
- cleanly, and we can't attach another netdde instance
-
-[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
-
-
-# IRC, freenode, #hurd, 2012-08-21
+## IRC, freenode, #hurd, 2012-08-21
In context of [[libpthread]].
@@ -513,6 +538,40 @@ In context of [[libpthread]].
<braunr> either in netdde or pfinet
+## IRC, freenode, #hurd, 2013-02-28
+
+ <braunr> (which needs the same kinds of fixes that libpthread got)
+ <braunr> actually i'm not sure why he didn't simply reuse the pthread
+ functions :/
+ <youpi> which kind of fixes?
+ <youpi> cancellation?
+ <braunr> timeouts
+ <braunr> cancellation too but that's less an issue
+ <youpi> I'm not sure it really needs timeout work
+ <youpi> on what RPC?
+ <youpi> pfinet is just using the mach interface
+ <braunr> i don't know but it clearly copies some of the previous pthread
+ code from pthread_cond_timedwait
+ <braunr> see libddekit/thread.c:_sem_timedwait_internal
+ <youpi> I recognize the comment indeed :)
+ <youpi> I guess he thought he might need some particular semantic that
+ libpthread may not provide
+ <braunr> also, now that i think about it, he couldn't have used libpthread,
+ could he ?
+ <braunr> and there was no condition_timedwait in cthreads
+ <braunr> there is a deadlock in netdde
+ <braunr> it occurs sometimes, at high network speeds
+ <braunr> (well high, 4 MiB/s or more)
+
+
+# IRC, freenode, #hurd, 2012-08-18
+
+ <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
+ cleanly, and we can't attach another netdde instance
+
+[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
+
+
# DDE for Filesystems
## IRC, freenode, #hurd, 2012-10-07
diff --git a/open_issues/gcc/pie.mdwn b/open_issues/gcc/pie.mdwn
index a4598d1e..da951001 100644
--- a/open_issues/gcc/pie.mdwn
+++ b/open_issues/gcc/pie.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -13,7 +13,7 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_gcc]]
-# IRC, freenode, #debian-hurd, 2012-11-08
+# IRC, freenode, #hurd, 2012-11-08
<pinotree> tschwinge: i'm not totally sure, but it seems the pie options
for gcc/ld are causing issues
@@ -38,3 +38,9 @@ License|/fdl]]."]]"""]]
<youpi> uh
<pinotree> this causes the w3m build failure and (indirectly, due to elinks
built with -pie) aptitude
+
+
+## IRC, freenode, #hurd, 2013-01-19
+
+ <gnu_srs> pinotree: I can confirm that -fPIE -pie fails and only -fPIE
+ works for mktable in w3m. Still have to check with elinks. What's up doc?
diff --git a/open_issues/git-core-2.mdwn b/open_issues/git-core-2.mdwn
index 2d8ad96b..cbf47bd2 100644
--- a/open_issues/git-core-2.mdwn
+++ b/open_issues/git-core-2.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2013 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
@@ -16,9 +16,7 @@ License|/fdl]]."]]"""]]
[[!toc]]
-# Log
-
-December, 2008.
+# 2008-12
On the otherwise-idle flubber:
@@ -57,11 +55,15 @@ Fixing this situation is easy enough:
# On branch master
nothing to commit (working directory clean)
-Still seen on 2010-03-16.
----
+## 2010-03-16
+
+Still seen.
+
-A very similar issue, seen on 2010-11-17. The working tree had a lot of
+# 2010-11-17
+
+A very similar issue. The working tree had a lot of
differences to HEAD.
tschwinge@grubber:~/tmp/gcc/hurd $ git reset --hard HEAD
@@ -92,9 +94,10 @@ differences to HEAD.
Checking out files: 100% (1149/1149), done.
HEAD is now at fe3e43c Merge commit 'refs/top-bases/hurd/master' into hurd/master
----
-2010-12-22, grubber:
+## 2010-12-22
+
+grubber:
$ git remote update
Fetching savannah
@@ -106,9 +109,10 @@ differences to HEAD.
fatal: index-pack failed
error: Could not fetch savannah
----
-2011-06-10, coulomb.SCHWINGE, checking out [[binutils]]' master branch,
+## 2011-06-10
+
+coulomb.SCHWINGE, checking out [[binutils]]' master branch,
starting from an empty working directory (after an external `git push`):
$ git checkout -f
@@ -144,7 +148,7 @@ starting from an empty working directory (after an external `git push`):
# Analysis
-2011-06-13
+## 2011-06-13
Running `git checkout -f` under GDB:
@@ -188,3 +192,25 @@ there are cases where `unlink` apparently returns EINTR, which is not kosher
either. Etc.
Do we have problems with `SA_RESTART` vs. the atomicity of our syscall-alikes?
+
+
+## IRC, freenode, #hurd, 2013-01-30
+
+ <braunr> hm, let's try to clone a huge repository
+ <braunr> hm, cloning a whole linux repo, and still no problem :)
+ <pinotree> weren't most/all the issues at unpack time?
+ <braunr> i don't remember
+ <braunr> we'll see when it gets there
+ <braunr> the longest part is "resolving deltas", for which ext2fs is
+ clearly the big bottleneck (no I/O, page-cache only, but still)
+ <braunr> pinotree: well, slow, but no error
+
+
+### IRC, freenode, #hurd, 2013-01-31
+
+ <braunr> fyi, i've tried several checkouts of big repositories, and never
+ got a single error
+ <braunr> youpi: looks like the recent fixes also solved some git issues we
+ had
+ <braunr> i could clone big repositories without any problem
+ <youpi> cool :)
diff --git a/open_issues/git_duplicated_content.mdwn b/open_issues/git_duplicated_content.mdwn
index cbc171a7..f0ffad77 100644
--- a/open_issues/git_duplicated_content.mdwn
+++ b/open_issues/git_duplicated_content.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -116,16 +116,13 @@ Some more copying:
No further difference.
----
-
$ git-new-workdir git master master
$ diff -x .git -ur tar_master/ master/ > master.diff
$ rm -rf ar_master* && (cd git/ && git archive master) | (mkdir ar_master && cd ar_master/ && tar -x) && diff -x .git -ru tar_master/ ar_master/ > ar_master.diff; ls -l ar_master.diff
$ (cd git/ && git archive master) | md5sum
----
-2011-06-13
+# 2011-06-13
-> [[git-core-2]]
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 4111700b..425ce827 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013 Free Software
Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -385,6 +385,51 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
<Tekk_> pinotree: undefined
<pinotree> expected, given the output above
+ * `getsockopt`, `setsockopt`
+
+ IRC, freenode, #hurd, 2013-02-14
+
+ <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows
+ e.g. in the gnulib's test-{poll,select} code.
+ <gnu_srs> Reading
+ http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might
+ be reasons _not_ to implement them, comments?
+ <pinotree> uh? they are supported on hurd
+ <gnu_srs> not SO_REUSEPORT for setsockopt()
+ <pinotree> that isn't the same as claiming "get/setsockopt is not
+ supported on hurd"
+ <pinotree> most probably that option is not implemented by the
+ socket family you are using
+ <gnu_srs> OK, some options like SO_REUSEPORT then, more info in
+ the link.
+ <pinotree> note also SO_REUSEPORT is not posix
+ <pinotree> and i don't see SO_REUSEPORT mentioned in the page you
+ linked
+ <gnu_srs> No, but SO_REUSEADDR
+
+ IRC, freenode, #hurd, 2013-02-23
+
+ <gnu_srs> as an example, the poll test code from gnulib fails due
+ to that problem (and I've told you before)
+ <pinotree> gnu_srs: what's the actual failure?
+ <pinotree> can you provide a minimal test case showing the issue?
+ <gnu_srs> pinotree: A smaller test program:
+ http://paste.debian.net/237495/
+ <pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket
+ works...
+ <pinotree> and it seems it was a bug in the gnulib tests, see
+ http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4
+ <gnu_srs> pinotree: You are right, still the code I pasted pass on
+ Linux, not on Hurd.
+ <pinotree> so?
+ <pinotree> the code is wrong
+ <pinotree> you cannot change what bind does after you have called
+ it
+ * pinotree → out
+ <gnu_srs> so linux is buggy?
+ <braunr> no, linux is more permissive
+ <braunr> (at least, on this matter)
+
For specific packages:
* [[octave]]
@@ -669,6 +714,198 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
[[!message-id "201211172058.21035.toscano.pino@tiscali.it"]].
+ In context of [[libpthread]].
+
+ IRC, freenode, #hurd, 2013-01-21
+
+ <braunr> ah, found something interesting
+ <braunr> tschwinge: there seems to be a race on our file descriptors
+ <braunr> the content written by one thread seems to be retained
+ somewhere and another thread writing data to the file descriptor will
+ resend what the first already did
+ <braunr> it could be a FILE race instead of fd one though
+ <braunr> yes, it's not at the fd level, it's above
+ <braunr> so good news, seems like the low level message/signalling code
+ isn't faulty here
+ <braunr> all right, simple explanation: our IO_lockfile functions are
+ no-ops
+ <pinotree> braunr: i found that out days ago, and samuel said they were
+ okay
+ <braunr> well, they're not no-ops in libpthreads
+ <braunr> so i suppose they replace the default libc stubs, yes
+ <pinotree> so the issue happens in cthreads-using apps?
+ <braunr> no
+ <braunr> we don't have cthreads apps any more
+ <braunr> and aiui, libpthreads provides cthreads compatibility calls to
+ libc, so everything is actually using pthreads
+ <braunr> more buffer management debugging needed :/
+ <pinotree> hm, so how can it be that there's a multithread app with no
+ libpthread-provided file locking?
+ <braunr> ?
+ <braunr> file locking looks fine
+ <braunr> hm, the recursive locking might be wrong though
+ <braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define
+ __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0))
+ <braunr> nop, looks fine too
+ <braunr> indeed, without stream buffering, the problem seems to go away
+ <braunr> pinotree: it really looks like the stub IO_flockfile is used
+ <braunr> i'll try to make sure it's the root of the problem
+ <pinotree> braunr: you earlier said that there's some race with
+ different threads, no?
+ <braunr> yes
+ <braunr> either a race or an error in the iostream management code
+ <braunr> but i highly doubt the latter
+ <pinotree> if the stub locks are used, then libpthread is not
+ loaded... so which different threads are running?
+ <braunr> that's the thing
+ <braunr> the libpthread versions should be used
+ <pinotree> so the application is linked to pthread?
+ <braunr> yes
+ <pinotree> i see, that was the detail i was missing earlier
+ <braunr> the common code looks fine, but i can see wrong values even
+ there
+ <braunr> e.g. when vfprintf calls write, the buffer is already wrong
+ <braunr> i've made similar tests on linux sid, and it behaves as it
+ should
+ <pinotree> hm
+ <braunr> i even used load to "slow down" my test program so that
+ preemption is much more likely to happen
+ <pinotree> note we have slightly different behaviour in glibc's libio,
+ ie different memory allocation ways (mmap on linux, malloc for us)
+ <braunr> the problem gets systematic on the hurd while it never occurs
+ on linux
+ <braunr> that shouldn't matter either
+ <pinotree> ok
+ <braunr> but i'll make sure it doesn't anyway
+ <braunr> this mach_print system call is proving very handy :)
+ <braunr> and also, with load, unbuffered output is always correct too
+ <pinotree> braunr: you could try the following hack
+ http://paste.debian.net/227106/
+ <braunr> what does it do ?
+ <pinotree> (yes, ugly as f**k)
+ <braunr> does it force libio to use mmap ?
+ <braunr> or rather, enable ?
+ <pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use
+ mmap (like on linux) instead of malloc
+
+ `t/pagesize`.
+
+ <braunr> yes, the stub is used instead of the libpthreads code
+ <braunr> tschwinge: ^
+ <braunr> i'll override those to check that it fixes the problem
+ <braunr> hm, not that easy actually
+ <pinotree> copy their files from libpthreads to sysdeps/mach/hurd
+ <pinotree> hm right, in libpthread they are not that split as in glibc
+ <braunr> let's check symbol declaration to understand why the stubs
+ aren't overriden by ld
+ <braunr> _IO_vfprintf correctly calls @plt versions
+ <braunr> i don't know enough about dynamic linking to see what causes
+ the problem :/
+ <braunr> youpi: it seems our stdio functions use the stub IO_flockfile
+ functions
+ <youpi> really? I thought we were going through cthreads-compat.c
+ <braunr> yes really
+ <braunr> i don't know why, but that's the origin of the "duplicated"
+ messages issue
+ <braunr> messages aren't duplicated, there is a race that makes on
+ thread reuse the content of the stream buffer
+ <braunr> one*
+ <youpi> k, quite bad
+ <braunr> at least we know where the problem comes from now
+ <braunr> youpi: what would be the most likely reason why weak symbols
+ in libc wouldn't be overriden by global ones from libpthread ?
+ <youpi> being loaded after libc
+ <braunr> i tried preloading it
+ <braunr> i'll compare with what is done on wheezy
+ <youpi> you have the local-dl-dynamic-weak.diff patch, right?
+ <braunr> (on squeeze, the _IO_flockfile function in libc seems to do
+ real work unlike our noop stub)
+ <braunr> it's the debian package, i have all patches provided there
+ <braunr> indeed, on linux, libc provides valid IO_flock functions
+ <braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile,
+ _IO_flockfile)
+ <braunr> that's how ntpl exports it
+ <braunr> nptl*
+ <pinotree> imho we should restructure libpthread to be more close to
+ nptl
+ <braunr> i wish i knew what it involves
+ <pinotree> file structing for sources and tests, for example
+ <braunr> well yes obviously :)
+ <braunr> i've just found a patch that does exactly that for linuxthreads
+ <pinotree> that = fix the file locking?
+ <braunr> in addition to linuxthreads/lockfile.c (which we also
+ equivalently provide), there is
+ linuxthreads/sysdeps/pthread/flockfile.c
+ <braunr> no, restructiring
+ <braunr> restructuring*
+ <braunr> i still have only a very limited idea of how the glibc sources
+ are organized
+ <pinotree> the latter is used as source file when compiling flockfile.c
+ in stdio-common
+ <braunr> shouldn't we provide one too ?
+ <pinotree> that would mean it would be compiled as part of libc proper,
+ not libpthread
+ <braunr> yes
+ <braunr> that's what both linuxthreads and nptl seem to do
+ <braunr> and the code is strictly the same, i.e. a call to the internal
+ _IO_lock_xxx functions
+ <youpi> I guess that's for the hot-dlopen case
+ <youpi> you need to have locks properly taken at dlopen time
+ <braunr> youpi: do you mean adding an flockfile.c file to our sysdeps
+ will only solve the problem by side effect ?
+ <braunr> and that the real problem is that the libpthread versions
+ aren't used ?
+ <youpi> yes
+ <braunr> ok
+ <braunr> youpi: could it simply be a versioning issue ?
+ <youpi> could be
+ <braunr> it seems so
+ <braunr> i've rebuilt with the flockfile functions versioned to 2.2.6
+ (same as in libc) and the cthreads_compat functions are now used
+ <braunr> and the problem doesn't occur any more with my test code
+ <braunr> :)
+ <youpi> could you post a patch?
+ <braunr> i need a few info before
+ <youpi> it'd be good to check which such functions are hooked
+ <braunr> i suppose the version for functions declared in libpthreads
+ shouldn't change, right ?
+ <youpi> yes
+ <braunr> ok
+ <youpi> they didn't have a vresion before
+ <braunr> shall i commit directly ?
+ <youpi> so it should be fine
+ <braunr> well, they did
+ <braunr> 2.12
+ <youpi> yes, but please tell me when it's done
+ <braunr> sure
+ <youpi> so I can commit that to debian's eglibc
+ <youpi> I mean, before we integrated libpthread build into glibc
+ <youpi> so they never had any version before 2.12
+ <braunr> ok
+ <youpi> basically we need to check the symbols which are both in
+ libpthread and referenced in libc
+ <youpi> to make sure they have the same version in the reference
+ <braunr> ok
+ <youpi> only weak references need to be checked, others would have
+ produced a runtime error
+ <braunr> youpi: done
+ <braunr> arg, the version i mention in the comment is wrong
+ <braunr> i suppose people understand nonetheless
+ <youpi> probably, yes
+ <braunr> ah, i can now appreciate the headache this bug hunting gave me
+ these last days :)
+
+ IRC, freenode, #hurd, 2013-01-22
+
+ <youpi> braunr: commited to debian glibc
+ <youpi> btw, it's normal that the program doesn't terminate, right?
+ <youpi> (i.e. it's the original bug you were chasing)
+ <braunr> youpi: about your earlier question (yesterday) about my test
+ code, it's expected to block, which is the problem i was initially
+ working on
+ <youpi> ok, so all god
+ <youpi> +o
+
* `t/pagesize`
IRC, freenode, #hurd, 2012-11-16
@@ -677,6 +914,37 @@ Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h
switches the allocation modes from mmap to malloc
+ IRC, freenode, #hurd, 2013-01-21
+
+ <braunr> why is it a hack ?
+ <pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE
+ like that
+ <braunr> ah
+ <pinotree> there's a mail from roland, replying to thomas about this
+ issue, that this use of EXEC_PAGESIZE to enable mmap or not is just
+ wrong
+ <braunr> ok
+ <pinotree> (the above is
+ http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net )
+ <braunr> thanks
+ <pinotree> (just added the reference to that in the wiki)
+ <braunr> pinotree: btw, what's wrong with using malloc instead of mmap
+ in libio ?
+ <pinotree> braunr: i'm still not totally sure, most probably it should
+ be slightly slower currently
+ <braunr> locking contention ?
+ <braunr> pinotree:
+ http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html
+ <braunr> pinotree: it looks to me there is now no valid reason not to
+ use malloc
+ <braunr> the best argument for mmap is that libio requires zeroed
+ memory, but as the OP says, zeroing a page is usually more expensive
+ than a small calloc (even on kernel that keep a list of zeroed pages
+ for quick allocations, frequent mmaps() often make this list empty)
+ <pinotree> braunr: mmap allocations in libio are rounded to the page
+ size
+ <braunr> well they have to
+
* `LD_DEBUG`
IRC, freenode, #hurd, 2012-11-22
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn
index 22b05953..5e93887e 100644
--- a/open_issues/gnumach_page_cache_policy.mdwn
+++ b/open_issues/gnumach_page_cache_policy.mdwn
@@ -771,12 +771,12 @@ License|/fdl]]."]]"""]]
<tschwinge> And set precedence.
-## IRC, freenode, #hurd, 2012-07-26
+# IRC, freenode, #hurd, 2012-07-26
<braunr> hm i killed darnassus, probably the page cache patch again
-## IRC, freenode, #hurd, 2012-09-19
+# IRC, freenode, #hurd, 2012-09-19
<youpi> I was wondering about the page cache information structure
<youpi> I guess the idea is that if we need to add a field, we'll just
@@ -786,3 +786,28 @@ License|/fdl]]."]]"""]]
<braunr> youpi: have a look at the rbraun/page_cache gnumach branch
<youpi> that's what I was referring to
<braunr> ok
+
+
+# IRC, freenode, #hurd, 2013-01-15
+
+ <braunr> hm, no wonder the page cache patch reduced performance so much
+ <braunr> the page cache when building even moderately large packages is
+ about a few dozens MiB (around 50)
+ <braunr> the patch enlarged it to several hundreds :/
+ <ArneBab> braunr: so the big page cache essentially killed memory locality?
+ <braunr> ArneBab: no, it made ext2fs crazy (disk translators - used as
+ pagers - scan their cached pages every 5 seconds to flush the dirty ones)
+ <braunr> you can imagine what happens if scanning and flushing a lot of
+ pages takes more than 5 seconds
+ <ArneBab> ouch… that’s heavy, yes
+ <ArneBab> I already see it pile up in my mindb
+ <braunr> and it's completely linear, using a lock to protect the whole list
+ <braunr> darnassus is currently showing such a behaviour, because tschwinge
+ is linking huge files (one object with lots of pages)
+ <braunr> 446 MB of swap used, between 200 and 1850 MiB of RAM used, and i
+ can still use vim and build stuff without being too disturbed
+ <braunr> the system does feel laggy, but there has been great stability
+ improvements
+ <braunr> have*
+ <braunr> and even if laggy, it doesn't feel much more than the usual lag of
+ a network (ssh) based session
diff --git a/open_issues/gnumach_panic_thread_dispatch.mdwn b/open_issues/gnumach_panic_thread_dispatch.mdwn
new file mode 100644
index 00000000..db094f2f
--- /dev/null
+++ b/open_issues/gnumach_panic_thread_dispatch.mdwn
@@ -0,0 +1,20 @@
+[[!meta copyright="Copyright © 2013 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_gnumach]]
+
+
+# IRC, freenode, #hurd, 2013-02-10
+
+ <youpi> panic: thread_dispatch: thread a958c950 has unexpected state 114
+ <youpi> hum ):
+ <braunr> ouch
+ <youpi> during a perl build
+ <braunr> TH_SWAPPED | TH_HALTED | TH_RUN
diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn
index 6146885d..574a03ec 100644
--- a/open_issues/hurd_101.mdwn
+++ b/open_issues/hurd_101.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -12,7 +12,8 @@ License|/fdl]]."]]"""]]
Not the first time that something like this is proposed...
-IRC, freenode, #hurd, 2011-07-25
+
+# IRC, freenode, #hurd, 2011-07-25
[failed GNU/Hurd project]
< antrik> gnu_srs1: I wouldn't say he was on track. just one of the many
@@ -39,3 +40,23 @@ IRC, freenode, #hurd, 2011-07-25
< Tekk_`> under the right conditions
< cluck> antrik: jokes aside some sort of triage system/training ground for
newcomers could be helpful
+
+
+# IRC, freenode, #hurd, 2013-01-20
+
+ <zacts> so once I have written my first translators, and really understand
+ that, what kinds of projects would you recommend to an operating
+ systems/hurd newbie.
+ <zacts> I am reading the minix book now as I have it, but I'm waiting on
+ getting the modern operating systems book by the same author.
+ <zacts> I was initially going to start working on minix, but their focus
+ seems to be on embedded, and I want to work on a system that is more
+ general purpose, and I like the philosophy of freedom surrounding the
+ hurd.
+ <zacts> I like how the hurd design allows more freedom for users of the
+ operating system, but I would also like to incorporate ideas from minix
+ on the hurd. mainly, rebootless updates of servers/translators.
+ <neal> then you should study how translators work
+ <neal> how ipc works
+ <neal> and understand exactly what state is stored where
+ <zacts> ok
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
index 80fe36f8..670c82cb 100644
--- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
+++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -121,3 +121,15 @@ License|/fdl]]."]]"""]]
libmachuser and libhurduser? should they be linked to explicitly, or
assume libc brings them?
<braunr> pinotree: libc should bring them
+
+
+# IRC, freenode, #hurd, 2013-02-25
+
+ <braunr> we should also discuss the mach_debug interface some day
+ <braunr> it's not exported by libc, but the kernel provides it
+ <braunr> slabinfo depends on it, and i'd like to include it in the hurd
+ <braunr> but i don't know what kind of security problems giving access to
+ mach_debug RPCs would create
+ <braunr> (imo, the mach_debug interface should be adjusted to be used with
+ privileged ports only)
+ <braunr> (well, maybe not all mach_debug RPCs)
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index 05aab85f..f0c0db58 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1170,6 +1170,12 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
<braunr> haven't tested
+### IRC, freenode, #hurd, 2013-01-26
+
+ <braunr> ah great, one of the recent fixes (probably select-eintr or
+ setitimer) fixed exim4 :)
+
+
## IRC, freenode, #hurd, 2012-09-23
<braunr> tschwinge: i committed the last hurd pthread change,
@@ -1270,6 +1276,17 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
<youpi> that's it, yes
+### IRC, freenode, #hurd, 2013-03-01
+
+ <youpi> braunr: btw, "unable to adjust libports thread priority: (ipc/send)
+ invalid destination port" is actually not a sign of fatality
+ <youpi> bach recovered from it
+ <braunr> youpi: well, it never was a sign of fatality
+ <braunr> but it means that, for some reason, a process looses a right for a
+ very obscure reason :/
+ <braunr> weird sentence, agreed :p
+
+
## IRC, freenode, #hurd, 2012-12-05
<braunr> tschwinge: i'm currently working on a few easy bugs and i have
@@ -1459,3 +1476,332 @@ Same issue as [[term_blocking]] perhaps?
<braunr> we have a similar problem with the hurd-specific cancellation
code, it's in my todo list with io_select
<youpi> ah, no, the condvar is not global
+
+
+## IRC, freenode, #hurd, 2013-01-14
+
+ <braunr> *sigh* thread cancellable is totally broken :(
+ <braunr> cancellation*
+ <braunr> it looks like playing with thread cancellability can make some
+ functions completely restart
+ <braunr> (e.g. one call to printf to write twice its output)
+
+[[git_duplicated_content]], [[git-core-2]].
+
+ * braunr is cooking a patch to fix pthread cancellation in
+ pthread_cond_{,timed}wait, smells good
+ <braunr> youpi: ever heard of something that would make libc functions
+ "restart" ?
+ <youpi> you mean as a feature, or as a bug ?
+ <braunr> when changing the pthread cancellation state of a thread, i
+ sometimes see printf print its output twice
+ <youpi> or perhaps after a signal dispatch?
+ <braunr> i'll post my test code
+ <youpi> that could be a duplicate write
+ <youpi> due to restarting after signal
+ <braunr> http://www.sceen.net/~rbraun/pthreads_test_cancel.c
+ #include <stdio.h>
+ #include <stdarg.h>
+ #include <stdlib.h>
+ #include <pthread.h>
+ #include <unistd.h>
+
+ static pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
+ static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;
+ static int predicate;
+ static int ready;
+ static int cancelled;
+
+ static void
+ uncancellable_printf(const char *format, ...)
+ {
+ int oldstate;
+ va_list ap;
+
+ va_start(ap, format);
+ pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, &oldstate);
+ vprintf(format, ap);
+ pthread_setcancelstate(oldstate, &oldstate);
+ va_end(ap);
+ }
+
+ static void *
+ run(void *arg)
+ {
+ uncancellable_printf("thread: setting ready\n");
+ ready = 1;
+ uncancellable_printf("thread: spin until cancellation is sent\n");
+
+ while (!cancelled)
+ sched_yield();
+
+ uncancellable_printf("thread: locking mutex\n");
+ pthread_mutex_lock(&mutex);
+ uncancellable_printf("thread: waiting for predicate\n");
+
+ while (!predicate)
+ pthread_cond_wait(&cond, &mutex);
+
+ uncancellable_printf("thread: unlocking mutex\n");
+ pthread_mutex_unlock(&mutex);
+ uncancellable_printf("thread: exit\n");
+ return NULL;
+ }
+
+ int
+ main(int argc, char *argv[])
+ {
+ pthread_t thread;
+
+ uncancellable_printf("main: create thread\n");
+ pthread_create(&thread, NULL, run, NULL);
+ uncancellable_printf("main: spin until thread is ready\n");
+
+ while (!ready)
+ sched_yield();
+
+ uncancellable_printf("main: sending cancellation\n");
+ pthread_cancel(thread);
+ uncancellable_printf("main: setting cancelled\n");
+ cancelled = 1;
+ uncancellable_printf("main: joining thread\n");
+ pthread_join(thread, NULL);
+ uncancellable_printf("main: exit\n");
+ return EXIT_SUCCESS;
+ }
+ <braunr> youpi: i'd see two calls to write, the second because of a signal,
+ as normal, as long as the second call resumes, but not restarts after
+ finishing :/
+ <braunr> or restarts because nothing was done (or everything was entirely
+ rolled back)
+ <youpi> well, with an RPC you may not be sure whether it's finished or not
+ <braunr> ah
+ <youpi> we don't really have rollback
+ <braunr> i don't really see the difference with a syscall there
+ <youpi> the kernel controls the interruption in the case of the syscall
+ <braunr> except that write is normally atomic if i'm right
+ <youpi> it can't happen on the way back to userland
+ <braunr> but that could be exactly the same with RPCs
+ <youpi> while perhaps it can happen on the mach_msg back to userland
+ <braunr> back to userland ok, back to the application, no
+ <braunr> anyway, that's a side issue
+ <braunr> i'm fixing a few bugs in libpthread
+ <braunr> and noticed that
+ <braunr> (i should soon have patches to fix - at least partially - thread
+ cancellation and timed blocking)
+ <braunr> i was just wondering how cancellation how handled in glibc wrt
+ libpthread
+ <youpi> I don't know
+ <braunr> (because the non standard hurd cancellation has nothing to do with
+ pthread cancellation)à
+ <braunr> ok
+ <braunr> s/how h/is h/
+
+
+### IRC, freenode, #hurd, 2013-01-15
+
+ <tschwinge> braunr: Re »one call to printf to write twice its output«:
+ sounds familiar:
+ http://www.gnu.org/software/hurd/open_issues/git_duplicated_content.html
+ and http://www.gnu.org/software/hurd/open_issues/git-core-2.html
+ <braunr> tschwinge: what i find strange with the duplicated operations i've
+ seen is that i merely use pthreads and printf, nothing else
+ <braunr> no setitimer, no alarm, no select
+ <braunr> so i wonder how cancellation/syscall restart is actually handled
+ in our glibc
+ <braunr> but i agree with you on the analysis
+
+
+### IRC, freenode, #hurd, 2013-01-16
+
+ <braunr> neal: do you (by any chance) remember if there could possibly be
+ spurious wakeups in your libpthread implementation ?
+ <neal> braunr: There probably are.
+ <neal> but I don't recall
+
+ <braunr> i think the duplicated content issue is due to the libmach/glibc
+ mach_msg wrapper
+ <braunr> which restarts a message send if interrupted
+ <tschwinge> Hrm, depending on which point it has been interrupted you mean?
+ <braunr> yes
+ <braunr> not sure yet and i could be wrong
+ <braunr> but i suspect that if interrupted after send and during receive,
+ the restart might be wrongfully done
+ <braunr> i'm currently reworking the timed* pthreads functions, doing the
+ same kind of changes i did last summer when working on select (since
+ implement the timeout at the server side requires pthread_cond_timedwait)
+ <braunr> and i limit the message queue size of the port used to wake up
+ threads to 1
+ <braunr> and it seems i have the same kind of problems, i.e. blocking
+ because of a second, unexpected send
+ <braunr> i'll try using __mach_msg_trap directly and see how it goes
+ <tschwinge> Hrm, mach/msg.c:__mach_msg does look correct to me, but yeah,
+ won't hurd to confirm this by looking what direct usage of
+ __mach_msg_trap is doing.
+ <braunr> tschwinge: can i ask if you still have a cthreads based hurd
+ around ?
+ <braunr> tschwinge: and if so, to send me libthreads.so.0.3 ... :)
+ <tschwinge> braunr: darnassus:~tschwinge/libthreads.so.0.3
+ <braunr> call 19c0 <mach_msg@plt>
+ <braunr> so, cthreads were also using the glibc wrapper
+ <braunr> and i never had a single MACH_SEND_INTERRUPTED
+ <braunr> or a busy queue :/
+ <braunr> (IOW, no duplicated messages, and the wrapper indeed looks
+ correct, so it's something else)
+ <tschwinge> (Assuming Mach is doing the correct thing re interruptions, of
+ course...)
+ <braunr> mach doesn't implement it
+ <braunr> it's explicitely meant to be done in userspace
+ <braunr> mach merely reports the error
+ <braunr> i checked the osfmach code of libmach, it's almost exactly the
+ same as ours
+ <tschwinge> Yeah, I meant Mach returns the interurption code but anyway
+ completed the RPC.
+ <braunr> ok
+ <braunr> i don't expect mach wouldn't do it right
+ <braunr> the only difference in osf libmach is that, when retrying,
+ MACH_SEND_INTERRUPT|MACH_RCV_INTERRUPT are both masked (for both the
+ send/send+receive and receive cases)
+ <tschwinge> Hrm.
+ <braunr> but they say it's for performance, i.e. mach won't take the slow
+ path because of unexpected bits in the options
+ <braunr> we probably should do the same anyway
+
+
+### IRC, freenode, #hurd, 2013-01-17
+
+ <braunr> tschwinge: i think our duplicated RPCs come from
+ hurd/intr-msg.c:148 (err == MACH_SEND_INTERRUPTED but !(option &
+ MACH_SEND_MSG))
+ <braunr> a thread is interrupted by a signal meant for a different thread
+ <braunr> hum no, still not that ..
+ <braunr> or maybe .. :)
+ <tschwinge> Hrm. Why would it matter for for the current thread for which
+ reason (different thread) mach_msg_trap returns *_INTERRUPTED?
+ <braunr> mach_msg wouldn't return it, as explained in the comment
+ <braunr> the signal thread would, to indicate the send was completed but
+ the receive must be retried
+ <braunr> however, when retrying, the original user_options are used again,
+ which contain MACH_SEND_MSG
+ <braunr> i'll test with a modified version that masks it
+ <braunr> tschwinge: hm no, doesn't fix anything :(
+
+
+### IRC, freenode, #hurd, 2013-01-18
+
+ <braunr> the duplicated rpc calls is one i find very very frustrating :/
+ <youpi> you mean the dup writes we've seen lately?
+ <braunr> yes
+ <youpi> k
+
+
+### IRC, freenode, #hurd, 2013-01-19
+
+ <braunr> all right, i think the duplicated message sends are due to thread
+ creation
+ <braunr> the duplicated message seems to be sent by the newly created
+ thread
+ <braunr> arg no, misread
+
+
+### IRC, freenode, #hurd, 2013-01-20
+
+ <braunr> tschwinge: youpi: about the diplucated messages issue, it seems to
+ be caused by two threads (with pthreads) doing an rpc concurrently
+ <braunr> duplicated*
+
+
+### IRC, freenode, #hurd, 2013-01-21
+
+ <braunr> ah, found something interesting
+ <braunr> tschwinge: there seems to be a race on our file descriptors
+ <braunr> the content written by one thread seems to be retained somewhere
+ and another thread writing data to the file descriptor will resend what
+ the first already did
+ <braunr> it could be a FILE race instead of fd one though
+ <braunr> yes, it's not at the fd level, it's above
+ <braunr> so good news, seems like the low level message/signalling code
+ isn't faulty here
+ <braunr> all right, simple explanation: our IO_lockfile functions are
+ no-ops
+ <pinotree> braunr: i found that out days ago, and samuel said they were
+ okay
+
+[[glibc]], `flockfile`/`ftrylockfile`/`funlockfile`.
+
+
+## IRC, freenode, #hurd, 2013-01-15
+
+ <braunr> hmm, looks like subhurds have been broken by the pthreads patch :/
+ <braunr> arg, we really do have broken subhurds :((
+ <braunr> time for an immersion in the early hurd bootstrapping stuff
+ <tschwinge> Hrm. Narrowed down to cthreads -> pthread you say.
+ <braunr> i think so
+ <braunr> but i think the problem is only exposed
+ <braunr> it was already present before
+ <braunr> even for the main hurd, i sometimes have systems blocking on exec
+ <braunr> there must be a race there that showed far less frequently with
+ cthreads
+ <braunr> youpi: we broke subhurds :/
+ <youpi> ?
+ <braunr> i can't start one
+ <braunr> exec seems to die and prevent the root file system from
+ progressing
+ <braunr> there must be a race, exposed by the switch to pthreads
+ <braunr> arg, looks like exec doesn't even reach main :(
+ <braunr> now, i'm wondering if it could be the tls support that stops exec
+ <braunr> although i wonder why exec would start correctly on a main hurd,
+ and not on a subhurd :(
+ <braunr> i even wonder how much progress ld.so.1 is able to make, and don't
+ have much idea on how to debug that
+
+
+### IRC, freenode, #hurd, 2013-01-22
+
+ <braunr> hm, subhurds seem to be broken because of select
+ <braunr> damn select !
+ <braunr> hm i see, we can't boot a subhurd that still uses libthreads from
+ a main hurd that doesn't
+ <braunr> the linker can't find it and doesn't start exec
+ <braunr> pinotree: do you understand what the fmh function does in
+ sysdeps/mach/hurd/dl-sysdep.c ?
+ <braunr> i think we broke subhurds by fixing vm_map with size 0
+ <pinotree> braunr: no idea, but i remember thomas talking about this code
+
+[[vm_map_kernel_bug]]
+
+ <braunr> it checks for KERN_INVALID_ADDRESS and KERN_NO_SPACE
+ <braunr> and calls assert_perror(err); to make sure it's one of them
+ <braunr> but now, KERN_INVALID_ARGUMENT can be returned
+ <braunr> ok i understand what it does
+ <braunr> and youpi has changed the code, so he does too
+ <braunr> (now i'm wondering why he didn't think of it when we fixed vm_map
+ size with 0 but his head must already be filled with other things so ..)
+ <braunr> anyway, once this is dealt with, we get subhurds back :)
+ <braunr> yes, with a slight change, my subhurd starts again \o/
+ <braunr> youpi: i found the bug that prevents subhurds from booting
+ <braunr> it's caused by our fixing of vm_map with size 0
+ <braunr> when ld.so.1 starts exec, the code in
+ sysdeps/mach/hurd/dl-sysdep.c fails because it doesn't expect the new
+ error code we introduced
+ <braunr> (the fmh functions)
+ <youpi> ah :)
+ <youpi> good :)
+ <braunr> adding KERN_INVALID_ARGUMENT to the list should do the job, but if
+ i understand the code correctly, checking if fmhs isn't 0 before calling
+ vm_map should do the work too
+ <braunr> s/do the work/work/
+ <braunr> i'm not sure which is the preferred way
+ <youpi> otherwise I believe fmh could be just fixed to avoid calling vm_map
+ in the !fmhs case
+ <braunr> yes that's what i currently do
+ <braunr> at the start of the loop, just after computing it
+ <braunr> seems to work so far
+
+
+## IRC, freenode, #hurd, 2013-01-22
+
+ <braunr> i have almost completed fixing both cancellation and timeout
+ handling, but there are still a few bugs remaining
+ <braunr> fyi, the related discussion was
+ https://lists.gnu.org/archive/html/bug-hurd/2012-08/msg00057.html
diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn
index 9abb7639..7a7a77ce 100644
--- a/open_issues/mach_tasks_memory_usage.mdwn
+++ b/open_issues/mach_tasks_memory_usage.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -8,9 +8,10 @@ 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_documentation]]
+[[!tag open_issue_documentation open_issue_gnumach]]
-IRC, freenode, #hurd, 2011-01-06
+
+# IRC, freenode, #hurd, 2011-01-06
<antrik> hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but
the sum of all RSS is <300 MiB... what's the rest?
@@ -100,7 +101,7 @@ IRC, freenode, #hurd, 2011-01-06
libraries
-IRC, freenode, #hurd, 2011-07-24
+# IRC, freenode, #hurd, 2011-07-24
< braunr> the panic is probably due to memory shortage
< braunr> so as antrik suggested, use more swap
@@ -145,3 +146,30 @@ IRC, freenode, #hurd, 2011-07-24
looks like it is on both seqnos_memory_object_data_initialize and
seqnos_memory_object_data_write
< braunr> antrik: so i guess reserved memory is accounted for
+
+
+# IRC, freenode, #hurd, 2013-01-12
+
+ <tschwinge> darnassus linking clang: 600 MiB swap in use and 22 MiB RAM
+ free, of 2 GiB. But ps shows a RSS of just 100 MiB, huh?
+ <tschwinge> Getting "better": near the end of the link, nearly 1 GiB swap
+ in use, and 200 KiB (!) RAM free.
+ <sobhan> can hurd have more than 1GB of ram ?
+ <tschwinge> And then it completed; 75 MiB swap in use, and 1.2 GiB RAM
+ free.
+ <braunr> tschwinge: unless i'm mistaken, mach uses the legacy "swapping"
+ bsd mechanism
+ <braunr> tschwinge: i.e. when it swaps a process, it swaps all of it
+ <braunr> tschwinge: the rest is probably one big anonymous vm object
+ containing the process space
+ <braunr> cached objects aren't currently well accounted
+ <braunr> (well, since youpi got my page cache patches in, they are, but
+ procfs isn't yet modified to report them)
+ <braunr> tschwinge: right, i'm currently looking at the machine and it
+ doesn't add up, i suppoe there are some big files still in the cache
+ <braunr> ah, git packed objects :p
+ <braunr> and a few llvm .a/.so/executable files too
+ <braunr> and since they're probably targets, they're built last, which
+ explains why they're retained in the cache for a while
+
+[[microkernel/mach/message/msgh_id]] (why on *that* page?).
diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn
index b32d6ba6..a1c8f235 100644
--- a/open_issues/mission_statement.mdwn
+++ b/open_issues/mission_statement.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 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
@@ -697,3 +698,11 @@ License|/fdl]]."]]"""]]
<braunr> nowhere_man: it can be used that way too
<braunr> functional programming is getting more and more attention
<braunr> so it's fine if you're a lisp fan really
+
+
+# IRC, freenode, #hurd, 2013-02-04
+
+ <civodul> BTW, it's weird that the mission statement linked from
+ hurd.gnu.org is in weblog/ and written in the first person
+ <braunr> yes
+ <braunr> very :)
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index f631a80b..d7804864 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -266,6 +266,94 @@ Tom Van Cutsem, 2009.
async by nature, will create messages floods anyway
+### IRC, freenode, #hurd, 2013-02-23
+
+ <braunr> hmm let's try something
+ <braunr> iirc, we cannot limit the max number of threads in libports
+ <braunr> but did someone try limiting the number of threads used by
+ libpager ?
+ <braunr> (the only source of system stability problems i currently have are
+ the unthrottled writeback requests)
+ <youpi> braunr: perhaps we can limit the amount of requests batched by the
+ ext2fs sync?
+ <braunr> youpi: that's another approach, yes
+ <youpi> (I'm not sure to understand what threads libpager create)
+ <braunr> youpi: one for each writeback request
+ <youpi> ew
+ <braunr> but it makes its own call to
+ ports_manage_port_operations_multithread
+ <braunr> i'll write a new ports_manage_port_operations_multithread_n
+ function that takes a mx threads parameter
+ <braunr> and see if it helps
+ <braunr> i thought replacing spin locks with mutexes would help, but it's
+ not enough, the true problem is simply far too much contention
+ <braunr> youpi: i still think we should increase the page dirty timeout to
+ 30 seconds
+ <youpi> wouldn't that actually increase the amount of request done in one
+ go?
+ <braunr> it would
+ <braunr> but other systems (including linux) do that
+ <youpi> but they group requests
+ <braunr> what linux does is scan pages every 5 seconds, and writeback those
+ who have been dirty for more than 30 secs
+ <braunr> hum yes but that's just a performance issue
+ <braunr> i mean, a separate one
+ <braunr> a great source of fs performance degradation is due to this
+ regular scan happenning at the same time regular I/O calls are made
+ <braunr> e.G. aptitude update
+ <braunr> so, as a first step, until the sync scan is truley optimized, we
+ could increase that interval
+ <youpi> I'm afraid of the resulting stability regression
+ <youpi> having 6 times as much writebacks to do
+ <braunr> i see
+ <braunr> my current patch seems to work fine for now
+ <braunr> i'll stress it some more
+ <braunr> (it limits the number of paging threads to 10 currently)
+ <braunr> but iirc, you fixed a deadlock with a debian patch there
+ <braunr> i think the case was a pager thread sending a request to the
+ kernel, and waiting for the kernel to call another RPC that would unblock
+ the pager thread
+ <braunr> ah yes it was merged upstream
+ <braunr> which means a thread calling memory_object_lock_request with sync
+ == 1 must wait for a memory_object_lock_completed
+ <braunr> so it can deadlock, whatever the number of threads
+ <braunr> i'll try creating two separate pools with a limited number of
+ threads then
+ <braunr> we probably have the same deadlock issue in
+ pager_change_attributes btw
+ <braunr> hm no, i can still bring a hurd down easily with a large i/o
+ request :(
+ <braunr> and now it just recovered after 20 seconds without any visible cpu
+ or i/o usage ..
+ <braunr> i'm giving up on this libpager issue
+ <braunr> it simply requires a redesign
+
+
+### IRC, freenode, #hurd, 2013-02-28
+
+ <smindinvern> so what causes the stability issues? or is that not really
+ known yet?
+ <braunr> the basic idea is that the kernel handles the page cache
+ <braunr> and writebacks aren't correctly throttled
+ <braunr> so a huge number of threads (several hundreds, sometimes
+ thousands) are created
+ <braunr> when this pathological state is reached, it's very hard to recover
+ because of the various sources of (low) I/O in the system
+ <braunr> a simple line sent to syslog increases the load average
+ <braunr> the solution requires reworking the libpager library, and probably
+ the libdiskfs one too, perhaps others, certainly also the pagers
+ <braunr> maybe the kernel too, i'm not sure
+ <braunr> i'd say so because it manages a big part of the paging policy
+
+
+### IRC, freenode, #hurd, 2013-03-02
+
+ <braunr> i think i have a simple-enough solution for the writeback
+ instability
+
+[[hurd/libpager]].
+
+
## Alternative approaches:
* <http://www.concurrencykit.org/>
@@ -273,7 +361,7 @@ Tom Van Cutsem, 2009.
* Continuation-passing style
* [[microkernel/Mach]] internally [[uses
- continuations|microkernel/mach/continuation]], too.
+ continuations|microkernel/mach/gnumach/continuation]], too.
* [[Erlang-style_parallelism]]
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
index 76788a53..e27d3018 100644
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -373,3 +373,17 @@ here.
<pochu> braunr: can't remember right now, either that or to fix a ftbfs in
debian
<youpi> iirc it's coreutils which wants proper nice levels
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-04
+
+ <Steap> Is it not possible to set the priority of a process to 1 ?
+ <Steap> these macros:
+ <Steap> #define MACH_PRIORITY_TO_NICE(prio) (2 * ((prio) - 12))
+ <Steap> #define NICE_TO_MACH_PRIORITY(nice) (12 + ((nice) / 2))
+ <Steap> are used in the setpriority() implementation of Hurd
+ <Steap> so setting a process' priority to 1 is just like setting it to 0
+ <youpi> Steap: that has already been discussed to drop the *2
+ <youpi> the issue is mach not supporting enough sched levels
+ <youpi> can be fixed, of course
+ <youpi> just nobody did yet
diff --git a/open_issues/ogi.mdwn b/open_issues/ogi.mdwn
index e4372dc0..c58d2ee1 100644
--- a/open_issues/ogi.mdwn
+++ b/open_issues/ogi.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2013 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
@@ -23,3 +23,32 @@ interesting.
checking copyright situation, also for thesis / w.r.t. university
project
+
+ IRC, freenode, #hurd, 2013-02-15:
+
+ <tschwinge> ogi: The question was rather (IIRC) whether your
+ university has the copyright of this project, given it was done
+ on their time.
+ <ogi> tschwinge: no problems with my university
+
+
+# IRC, freenode, #hurd, 2013-02-15
+
+ <ogi> braunr: i want to update my ext3fs server to ext4 actually
+ <braunr> you have an ext3 server ?
+ <ogi> braunr: this was my M.Sc. thesis and the 2G patch was a side effect
+ <ogi> braunr: but it easily crashes under stress, so not usable
+ <braunr> it does ?
+ <ogi> braunr: it's not available for download ATM
+ <braunr> are you sure it's not a thread storm issue caused by the
+ unthrottled mach writebacks ?
+ <ogi> braunr: i don't know, haven't looked at it since 2004
+ <braunr> oh :)
+ <braunr> ok
+ <ogi> i have all ext3fs stuff archived, just haven't put it on
+ http://fire.tower.3.bg/ yet
+ <tschwinge> ogi: If the copyright situation is clear, we can put it into
+ upstream Git repositories, no matter how dirty it is.
+ <tschwinge> "dirty" in the sense of that it needs cleanup, has bugs, etc.
+ <ogi> so at some point i want to audit libdiskfs and then continue with
+ ext4fs: https://savannah.gnu.org/patch/?1839
diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index 18f124b4..171dc7a0 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -155,6 +155,30 @@ cherry-picked.
upstream
+## IRC, OFTC, #debian-hurd, 2013-02-08
+
+ <tschwinge> I also have it on my (never-ending) agenda to add libpthread to
+ the tschwinge/Roger_Whittaker branch and/or propose it be added upstream
+ (as a Git submodule?).
+ <pinotree> imho a git submodule could be a solution, if glibc people would
+ accept it
+ <pinotree> if so, libpthread.git would need proper glibc/x.y branches to
+ follow glibc
+ <tschwinge> Yep.
+ <tschwinge> I though that would be the least invasive approach for glibc
+ upstream -- and quite convenient for us, too.
+ <pinotree> after all, git submodules don't track branches, but point to
+ specific commits, no?
+ <tschwinge> Correct.
+ <tschwinge> So we can do locally/in Debian whatever we want, and every once
+ in a while update the upstream glibc commit ID for libpthread.
+ <pinotree> so we could update the git submodule references in glibc when
+ we've tested enough libpthread changes
+ <tschwinge> Just like when committing patches upstream, just without
+ pestering them with all the patches/commits.
+ <tschwinge> Yep.
+
+
# IRC, freenode, #hurd, 2012-11-16
<pinotree> *** $(common-objpfx)resolv/gai_suspend.o: uses
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 706e1632..be582e8a 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 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
@@ -2556,3 +2557,429 @@ License|/fdl]]."]]"""]]
<braunr> you're asking if you can include the large store patch in your
work, and by extension, in the main branch
<braunr> i would say yes, but this must be discussed with others
+
+
+## IRC, freenode, #hurd, 2013-02-18
+
+ <braunr> mcsim: so, currently reviewing gnumach
+ <mcsim> braunr: hello
+ <braunr> mcsim: the review branch, right ?
+ <mcsim> braunr: yes
+ <mcsim> braunr: What do you start with?
+ <braunr> memory refreshing
+ <braunr> i see you added the advice twice, to vm_object and vm_map_entry
+ <braunr> iirc, we agreed to only add it to map entries
+ <braunr> am i wrong ?
+ <mcsim> let me see
+ <braunr> the real question being: what do you use the object advice for ?
+ <mcsim> >iirc, we agreed to only add it to map entries
+ <mcsim> braunr: TBH, do not remember that. At some point we came to
+ conclusion that there should be only one advice. But I'm not sure if it
+ was final point.
+ <braunr> maybe it wasn't, yes
+ <braunr> that's why i've just reformulated the question
+ <mcsim> if (map_entry && (map_entry->advice != VM_ADVICE_DEFAULT))
+ <mcsim> advice = map_entry->advice;
+ <mcsim> else
+ <mcsim> advice = object->advice;
+ <braunr> ok
+ <mcsim> It just participates in determining actual advice
+ <braunr> ok that's not a bad thing
+ <braunr> let's keep it
+ <braunr> please document VM_ADVICE_KEEP
+ <braunr> and rephrase "How to handle page faults" in vm_object.h to
+ something like 'How to tune page fault handling"
+ <braunr> mcsim: what's the point of VM_ADVICE_KEEP btw ?
+ <mcsim> braunr: Probably it is better to remove it?
+ <braunr> well if it doesn't do anything, probably
+ <mcsim> braunr: advising was part of mo_set_attributes before
+ <mcsim> no it is redudant
+ <braunr> i see
+ <braunr> so yes, remove it
+ <mcsim> s/no/now
+ <braunr> (don't waste time on a gcs-like changelog format for now)
+ <braunr> i also suggest creating _vX branches
+ <braunr> so we can compare the changes between each of your review branches
+ <braunr> hm, minor coding style issues like switch(...) instead of switch
+ (...)
+ <braunr> why does syscall_vm_advise return MACH_SEND_INTERRUPTED if the
+ target map is NULL ?
+ <braunr> is it modelled after an existing behaviour ?
+ <braunr> ah, it's the syscall version
+ <mcsim> braunr: every syscall does so
+ <braunr> and the error is supposed to be used by user stubs to switch to
+ the rpc version
+ <braunr> ok
+ <braunr> hm
+ <braunr> you've replaced obsolete port_set_select and port_set_backup calls
+ with your own
+ <braunr> don't do that
+ <braunr> instead, add your calls to the new gnumach interface
+ <braunr> mcsim: out of curiosity, have you actually tried the syscall
+ version ?
+ <mcsim> braunr: Isn't it called by default?
+ <braunr> i don't think so, no
+ <mcsim> than no
+ <braunr> ok
+ <braunr> you could name vm_get_advice_info vm_advice_info
+ <mcsim> regarding obsolete calls, did you say that only in regard of
+ port_set_* or all other calls too?
+ <braunr> all of the
+ <braunr> m
+ <braunr> i missed one, yes
+ <braunr> the idea is: don't change the existing interface
+ <mcsim> >you could name vm_get_advice_info vm_advice_info
+ <mcsim> could or should? i.e. rename?
+ <braunr> i'd say should, to remain consistent with the existing similar
+ calls
+ <mcsim> ok
+ <braunr> can you explain KERN_NO_DATA a bit more ?
+ <braunr> i suppose it's what servers should answer for neighbour pages that
+ don't exist in the backend, right ?
+ <mcsim> kernel can ask server for some data to read them beforehand, but
+ server can be in situation when it does not know what data should be
+ prefetched
+ <mcsim> yes
+ <braunr> ok
+ <mcsim> it is used by ext2 server
+ <mcsim> with large store patch
+ <braunr> so its purpose is to allow the kernel to free the preallocated
+ pages that won't be used
+ <braunr> do i get it right ?
+ <mcsim> no.
+ <mcsim> ext2 server has a buffer for pages and when kernel asks to read
+ pages ahead it specifies region of that buffer
+ <braunr> ah ok
+ <mcsim> but consecutive pages in buffer does not correspond to consecutive
+ pages on disk
+ <braunr> so, the kernel can only prefetch pages that were already read by
+ the server ?
+ <mcsim> no, it can ask a server to prefetch pages that were not read by
+ server
+ <braunr> hum
+ <braunr> ok
+ <mcsim> but in case with buffer, if buffer page is empty, server does not
+ know what to prefetch
+ <braunr> i'm not sure i'm following
+ <braunr> well, i'm sure i'm not following
+ <braunr> what happens when the kernel requests data from a server, right
+ after a page fault ?
+ <braunr> what does the message afk for ?
+ <mcsim> kernel is unaware regarding actual size of file where was page
+ fault because of buffer indirection, right?
+ <braunr> i don't know what "buffer" refers to here
+ <mcsim> this is buffer in memory where ext2 server reads pages
+ <mcsim> with large store patch ext2 server does not map the whole disk, but
+ some of its pages
+ <mcsim> and it maps these pages in special buffer
+ <mcsim> that means that constructiveness of pages in memory does not mean
+ that they are consecutive on disk or logically (belong to the same file)
+ <braunr> ok so it's a page pool
+ <braunr> with unordered pages
+ <braunr> but what do you mean when you say "server does not know what to
+ prefetch"
+ <braunr> it normally has everything to determine that
+ <mcsim> For instance, page fault occurs that leads to reading of
+ 4k-file. But kernel does not know actual size of file and asks to
+ prefetch 16K bytes
+ <braunr> yes
+ <mcsim> There is no sense to prefetch something that does not belong to
+ this file
+ <braunr> yes but the server *knows* that
+ <mcsim> and server answers with KERN_NO_DATA
+ <mcsim> server should always say something about every page that was asked
+ <braunr> then, again, isn't the purpose of KERN_NO_DATA to notify the
+ kernel it can release the preallocated pages meant for the non existing
+ data ?
+ <braunr> (non existing or more generally non prefetchable)
+ <mcsim> yes
+ <braunr> then
+ <braunr> why did you answer no to
+ <braunr> 15:46 < braunr> so its purpose is to allow the kernel to free the
+ preallocated pages that won't be used
+ <braunr> is there something missing ?
+ <braunr> (well obviously, notify the kernel it can go on with page fault
+ handling)
+ <mcsim> braunr: sorry, misunderstoo/misread
+ <braunr> ok
+ <braunr> so good, i got this right :)
+ <braunr> i wonder if KERN_NO_DATA may be a bit too vague
+ <braunr> people might confuse it with ENODATA
+ <mcsim> Actually, this is transformation of ENODATA
+ <mcsim> I was looking among POSIX error codes and thought that this is the
+ most appropriate
+ <braunr> i'm not sure it is
+ <braunr> first, it's about STREAMS, a commonly unused feature
+ <braunr> and second, the code is obsolete
+ <mcsim> braunr: AFAIR purpose of KERN_NO_DATA is not only free
+ pages. Without this call something should hang
+ <braunr> 15:59 < braunr> (well obviously, notify the kernel it can go on
+ with page fault handling)
+ <mcsim> yes
+ <braunr> hm
+ <mcsim> sorry again
+ <braunr> i don't see anything better for the error name for now
+ <braunr> and it's really minor so let's keep it as it is
+ <braunr> actually, ENODATA being obsolete helps here
+ <braunr> ok, done for now, work calling
+ <braunr> we'll continue later or tomorrow
+ <mcsim> braunr: ok
+ <braunr> other than that, this looks ok on the kernel side for now
+ <braunr> the next change is a bit larger so i'd like to take the time to
+ read it
+ <mcsim> braunr: ok
+ <mcsim> regarding moving calls in mach.defs, can I put them elsewhere?
+ <braunr> gnumach.defs
+ <braunr> you'll probably need to rebase your changes to get it
+ <mcsim> braunr: I'll rebase this later, when we finish with review
+ <braunr> ok
+ <braunr> keep the comments in a list then, not to forget
+ <braunr> (logging irc is also useful)
+
+
+## IRC, freenode, #hurd, 2013-02-20
+
+ <braunr> mcsim: why does VM_ADVICE_DEFAULT have its own entry ?
+ <mcsim> braunr: this kind of fallback mode
+ <mcsim> i suppose that even random strategy could even read several pages
+ at once
+ <braunr> yes
+ <braunr> but then, why did you name it "default" ?
+ <mcsim> because it is assigned by default
+ <braunr> ah
+ <braunr> so you expect pagers to set something else
+ <braunr> for all objects they create
+ <mcsim> yes
+ <braunr> ok
+ <braunr> why not, but add a comment please
+ <mcsim> at least until all pagers will support clustered reading
+ <mcsim> ok
+ <braunr> even after that, it's ok
+ <braunr> just say it's there to keep the previous behaviour by default
+ <braunr> so people don't get the idea of changing it too easily
+ <mcsim> comment in vm_advice.h?
+ <braunr> no, in vm_fault.C
+ <braunr> right above the array
+ <braunr> why does vm_calculate_clusters return two ranges ?
+ <braunr> also, "Function PAGE_IS_NOT_ELIGIBLE is used to determine if",
+ PAGE_IS_NOT_ELIGIBLE doesn't look like a function
+ <mcsim> I thought make it possible not only prefetch range, but also free
+ some memory that is not used already
+ <mcsim> braunr: ^
+ <mcsim> but didn't implement it :/
+ <braunr> don't overengineer it
+ <braunr> reduce to what's needed
+ <mcsim> braunr: ok
+ <mcsim> braunr: do you think it's worth to implement?
+ <braunr> no
+ <mcsim> braunr: it could be useful for sequential policy
+ <braunr> describe what you have in mind a bit more please, i think i don't
+ have the complete picture
+ <mcsim> with sequential policy user supposed to read strictly in sequential
+ order, so pages that user is not supposed to read could be put in unused
+ list
+ <braunr> what pages the user isn't supposed to read ?
+ <mcsim> if user read pages in increasing order than it is not supposed to
+ read pages that are right before the page where page fault occured
+ <braunr> right ?
+ <braunr> do you mean higher ?
+ <mcsim> that are before
+ <braunr> before would be lower then
+ <braunr> oh
+ <braunr> "right before"
+ <mcsim> yes :)
+ <braunr> why not ?
+ <braunr> the initial assumption, that MADV_SEQUENTIAL expects *strict*
+ sequential access, looks wrong
+ <braunr> remember it's just a hint
+ <braunr> a user could just acces pages that are closer to one another and
+ still use MADV_SEQUENTIAL, expecting a speedup because pages are close
+ <braunr> well ok, this wouldn't be wise
+ <braunr> MADV_SEQUENTIAL should be optimized for true sequential access,
+ agreed
+ <braunr> but i'm not sure i'm following you
+ <mcsim> but I'm not going to page these pages out. Just put in unused
+ list, and if they will be used later they will be move to active list
+ <braunr> your optimization seem to be about freeing pages that were
+ prefetched and not actually accessed
+ <braunr> what's the unused list ?
+ <mcsim> inactive list
+ <braunr> ok
+ <braunr> so that they're freed sooner
+ <mcsim> yes
+ <braunr> well, i guess all neighbour pages should first be put in the
+ inactive list
+ <braunr> iirc, pages in the inactive list aren't mapped
+ <braunr> this would force another page fault, with a quick resolution, to
+ tell the vm system the page was actually used, and must become active,
+ and paged out later than other inactive pages
+ <braunr> but i really think it's not worth doing it now
+ <braunr> clustered pagins is about improving I/O
+ <braunr> page faults without I/O are orders of magnitude faster than I/O
+ <braunr> it wouldn't bring much right now
+ <mcsim> ok, I remove this, but put in TODO
+ <mcsim> I'm not sure that right list is inactive list, but the list that is
+ scanned to pageout pages to swap partition. There should be such list
+ <braunr> both the active and inactive are
+ <braunr> the active one is scanned when the inactive isn't large enough
+ <braunr> (the current ratio of active pages is limited to 1/3)
+ <braunr> (btw, we could try increasing it to 1/2)
+ <braunr> iirc, linux uses 1/2
+ <braunr> your comment about unlock_request isn't obvious, i'll have to
+ reread again
+ <braunr> i mean, the problem isn't obvious
+ <braunr> ew, functions with so many indentation levels :/
+ <braunr> i forgot how ugly some parts of the mach vm were
+ <braunr> mcsim: basically it's ok, i'll wait for the simplified version for
+ another pass
+ <mcsim> simplified?
+ <braunr> 22:11 < braunr> reduce to what's needed
+ <mcsim> ok
+ <mcsim> and what comment?
+ <braunr> your XXX in vm_fault.c
+ <braunr> when calling vm_calculate_clusters
+ <mcsim> is m->unlock_request the same for all cluster or I should
+ recalculate it for every page?
+ <mcsim> s/all/whole
+ <braunr> that's what i say, i'll have to come back to that later
+ <braunr> after i have reviewed the userspace code i think
+ <braunr> so i understand the interactions better
+ <mcsim> braunr: pushed v1 branch
+ <mcsim> braunr: "Move new calls to gnumach.defs file" and "Implement
+ putting pages in inactive list with sequential policy" are in my TODO
+ <braunr> mcsim: ok
+
+
+## IRC, freenode, #hurd, 2013-02-24
+
+ <braunr> mcsim: where does the commit from neal (reworking libpager) come
+ from ?
+ <braunr> (ok the question looks a little weird semantically but i think you
+ get my point)
+ <mcsim> braunr: you want me to give you a link to mail with this commit?
+ <braunr> why not, yes
+ <mcsim> http://permalink.gmane.org/gmane.os.hurd.bugs/446
+ <braunr> ok so
+ http://lists.gnu.org/archive/html/bug-hurd/2012-06/msg00001.html
+ <braunr> ok so, we actually have three things to review here
+ <braunr> that libpager patch, the ext2fs large store one, and your work
+ <braunr> mcsim: i suppose something in your work depends on neal's patch,
+ right ?
+ <braunr> i mean, why did you work on top of it ?
+ <mcsim> Yes
+ <mcsim> All user level code
+ <braunr> i see it adds some notifications
+ <mcsim> no
+ <mcsim> notifacations are for large store
+ <braunr> ok
+ <mcsim> but the rest is for my work
+ <braunr> but what does it do that you require ?
+ <mcsim> braunr: this patch adds support for multipage work. There were just
+ stubs that returned errors for chunks longer than one page before.
+ <braunr> ok
+ <braunr> for now, i'll just consider that it's ok, as well as the large
+ store patch
+ <braunr> ok i've skipped all patches up to "Make mach-defpager process
+ multipage requests in m_o_data_request." since they're obvious
+ <braunr> but this one isn't
+ <braunr> mcsim: why is the offset member a vm_size_t in struct block ?
+ <braunr> (these things matter for large file support on 32-bit systems)
+ <mcsim> braunr: It should be vm_offset_t, right?
+ <braunr> yes
+ <braunr> well
+ <braunr> it seems so but
+ <braunr> im not sure what offset is here
+ <braunr> vm_offset is normally the offset inside a vm_object
+ <braunr> and if we want large file support, it could become a 64-bit
+ integer
+ <braunr> while vm_size_t is a size inside an address space, so it's either
+ 32 or 64-bit, depending on the address space size
+ <braunr> but here, if offset is an offset inside an address space,
+ vm_size_t is fine
+ <braunr> same question for send_range_parameters
+ <mcsim> braunr: TBH, I do not differ vm_size_t and vm_offset_t well
+ <braunr> they can be easily confused yes
+ <braunr> they're both offsets and sizes actually
+ <braunr> they're integers
+ <mcsim> so here I used vm_offset_t because field name is offset
+ <braunr> but vm_size_t is an offset/size inside an address space (a
+ vm_map), while vm_offset_t is an offset/size inside an object
+ <mcsim> braunr: I didn't know that
+ <braunr> it's not clear at all
+ <braunr> and it may not have been that clear in mach either
+ <braunr> but i think it's best to consider them this way from now on
+ <braunr> well, it's not that important anyway since we don't have large
+ file support, but we should some day :/
+ <braunr> i'm afraid we'll have it as a side effect of the 64-bit port
+ <braunr> mcsim: just name them vm_offset_t when they're offsets for
+ consistency
+ <mcsim> but seems that I guessed, because I use vm_offset_t variables in
+ mo_ functions
+ <braunr> well ok, but my question was about struct block
+ <braunr> where you use vm_size_t
+ <mcsim> braunr: I consider this like a mistake
+ <braunr> ok
+ <braunr> moving on
+ <braunr> in upload_range, there are two XXX comments
+ <braunr> i'm not sure to understand
+ <mcsim> Second XXX I put because at the moment when I wrote this not all
+ hurd libraries and servers supported size different from vm_page_size
+ <mcsim> But then I fixed this and replaced vm_page_size with size in
+ page_read_file_direct
+ <braunr> ok then update the comment accordingly
+ <mcsim> When I was adding third XXX, I tried to check everything. But I
+ still had felling that I forgot something.
+ <mcsim> No it is better to remove second and third XXX, since I didn't find
+ what I missed
+ <braunr> well, that's what i mean by "update" :)
+ <mcsim> ok
+ <mcsim> and first XXX just an optimisation. Its idea is that there is no
+ case when the whole structure is used in one function.
+ <braunr> ok
+ <mcsim> But I was not sure if was worth to do, because if there will appear
+ some bug in future it could be hard to find it.
+ <mcsim> I mean that maintainability decreases because of using union
+ <mcsim> So, I'd rather keep it like it is
+ <braunr> how is struct send_range_parameters used ?
+ <braunr> it doesn't looked to be something stored long
+ <braunr> also, you're allowed to use GNU extensions
+ <mcsim> It is used to pass parameters from one function to another
+ <mcsim> which of them?
+ <braunr> see
+ http://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Unnamed-Fields.html#Unnamed-Fields
+ <braunr> mcsim: if it's used to pass parameters, it's likely always on the
+ stack
+ <mcsim> braunr: I use it when necessary
+ <braunr> we really don't care much about a few extra words on the stack
+ <braunr> the difference in size would
+ <mcsim> agree
+ <braunr> matter
+ <braunr> oops
+ <braunr> the difference in size would matter if a lot of those were stored
+ in memory for long durations
+ <braunr> that's not the case, so the size isn't a problem, and you should
+ remove the comment
+ <mcsim> ok
+ <braunr> mcsim: if i get it right, the libpager rework patch changes some
+ parameters from byte offset to page frame numbers
+ <mcsim> braunr: yes
+ <braunr> why don't you check errors in send_range ?
+ <mcsim> braunr: it was absent in original code, but you're right, I should
+ do this
+ <braunr> i'm not sure how to handle any error there, but at least an assert
+ <mcsim> I found a place where pager just panics
+ <braunr> for now it's ok
+ <braunr> your work isn't about avoiding panics, but there must be a check,
+ so if we can debug it and reach that point, we'll know what went wrong
+ <braunr> i don't understand the prototype change of default_read :/
+ <braunr> it looks like it doesn't return anything any more
+ <braunr> has it become asynchronous ?
+ <mcsim> It was returning some status before, but now it handles this status
+ on its own
+ <braunr> hum
+ <braunr> how ?
+ <braunr> how do you deal with errors ?
+ <mcsim> in old code default_read returned kr and this kr was used to
+ determine what m_o_ function will be used
+ <mcsim> now default_read calls m_o_ on its own
+ <braunr> ok
diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn
new file mode 100644
index 00000000..387ad4fe
--- /dev/null
+++ b/open_issues/pfinet_timers.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2013 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_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-02-11
+
+ <braunr> now that there is a pthread_hurd_cond_timedwait_np function
+ available, we could replace the ulgy timers in pfinet
diff --git a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
index dfdc213c..d252eb54 100644
--- a/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
+++ b/open_issues/pflocal_socket_credentials_for_local_sockets.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -8,10 +8,11 @@ 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]]."]]"""]]
-IRC, freenode, #hurd, 2011-03-28
-
[[!tag open_issue_hurd]]
+
+# IRC, freenode, #hurd, 2011-03-28
+
<pinotree> basically, i'm trying to implement socket credentials for local
sockets, and i guessed doing it in pflocal would be the appropriate place
<pinotree> what i thought was filling the cmsg data for MSG_CRED at
@@ -41,6 +42,25 @@ IRC, freenode, #hurd, 2011-03-28
<youpi> yes
<pinotree> nice thanks, i will try that change first
+
+# IRC, OFTC, #debian-hurd, 2013-02-20
+
+ <pinotree> youpi: while debugging #700530, it seems that xorg does not have
+ working socket credentials on kfreebsd (and hurd too)
+ <pinotree> julien provided sune with
+ http://people.debian.org/~jcristau/kbsd-peercred.diff to test, but of
+ course that won't work for us (even if we would have working socket
+ credentials with cmsg)
+ <pinotree> (that patch is not tested yet)
+ <pinotree> at least, we're aware there's another place in need for working
+ socket credentials now
+ <youpi> k
+ <pinotree> youpi: (the patch above has been confirmed to work, with
+ s/SOL_SOCKET/0/ )
+ <youpi> 0 ?!
+ <pinotree> yeah
+
+
---
See also [[pflocal_reauth]] and [[sendmsg_scm_creds]].
diff --git a/open_issues/ps_SIGSEGV.mdwn b/open_issues/ps_SIGSEGV.mdwn
new file mode 100644
index 00000000..24d5cb4f
--- /dev/null
+++ b/open_issues/ps_SIGSEGV.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2013 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_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-02-05
+
+ <braunr> ps -l segfaults
+ <braunr> ah, perhaps because of the subhurd
diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
index 05eb53b8..d4622d67 100644
--- a/open_issues/rpc_stub_generator.mdwn
+++ b/open_issues/rpc_stub_generator.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -97,3 +97,50 @@ License|/fdl]]."]]"""]]
scatter-gather to be used with x15
<braunr> once more, i fell back on omg idl
<braunr> oh, there is also flick that looks interesting
+
+
+# IRC, freenode, #hurd, 2013-13-16
+
+ <tschwinge> braunr: By the way, regarding your recent IDL considerations
+ (and I too suggest using some kind of RPC generator basone on whichever
+ IDL) -- are you aware that for Viengoos, Neal has written a RPC stub
+ generator entirely in C Preprocessor macros? No idea whather that's
+ suitable for your case, but may be worth having a look at.
+ <neal> it probably isn't easy to port to Mach
+ <neal> genode has an ipc generator as well
+ <neal> which is written in a real langugage
+ <neal> that might be worth checking out as well
+ <neal> (note: I haven't followed the conversation at all.)
+ <braunr> i was considering using macros only too actually
+ <braunr> (i thought genode had switched to complex c++ templates)
+ <neal> dunno
+ <neal> I'm not up to date
+ <neal> macros are nice, but marshalling complicated data structures is hard
+ <sekon_> why implement it with just macros ??
+ <neal> no lexer, no parser
+ <neal> no special special tools
+ <neal> the first are a burden
+ <neal> the latter is a pain
+ <neal>
+ http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git;a=blob;f=libviengoos/viengoos/rpc.h;h=721768358a0299637fb79f226aea6a304571da85;hb=refs/heads/viengoos-on-bare-metal
+ <neal> in the same directory, you there are headers that use it
+ <braunr> neal: cf. http://genode.org/documentation/release-notes/11.05
+ <braunr> tschwinge: why do you recommend an IDL ?
+ <neal> braunr: What about it?
+ <braunr> neal: it shows the difference between the earlier ipc/rpc
+ interface, and the new one based only on templates and dynamic
+ marshalling using c++ streams
+ <neal> ok
+ <tschwinge> braunr: In my book, the definition of RPC interfaces is just
+ "data" in the sense that it describes data structures (exchanged
+ messages) and as such should be expressed as data (by means of an IDL),
+ instead of directly codifying it in a specific programming language.
+ <tschwinge> Of course, there may be other reasons for doing the latter
+ anyway, such as performance/optimization reasons.
+ <braunr> tschwinge: well, from my pov, you're justifying the use of an idl
+ from the definition of an rpc
+ <braunr> i'm not sure it makes much sense for me
+ <braunr> in addition, the idl becomes the "specific programming language"
+ <tschwinge> Well, I see it as data that has to be translated into several
+ formats: different programming languages' stub code.
+ <braunr> you could consider c the "common" language :)
diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn
index 391509a9..caecc437 100644
--- a/open_issues/select.mdwn
+++ b/open_issues/select.mdwn
@@ -215,7 +215,7 @@ IRC, unknown channel, unknown date:
<youpi> it's better than nothing yes
-# IRC, freenode, #hurd, 2012-07-21
+### IRC, freenode, #hurd, 2012-07-21
<braunr> damn, select is actually completely misdesigned :/
<braunr> iiuc, it makes servers *block*, in turn :/
@@ -315,7 +315,7 @@ IRC, unknown channel, unknown date:
really easy and nice :-)
-## IRC, freenode, #hurd, 2012-07-22
+#### IRC, freenode, #hurd, 2012-07-22
<braunr> antrik: you can't block in servers with sync ipc
<braunr> so in this case, "select" becomes a request for notifications
@@ -379,7 +379,7 @@ IRC, unknown channel, unknown date:
his reasoning (as does braunr)
-## IRC, freenode, #hurd, 2012-07-23
+#### IRC, freenode, #hurd, 2012-07-23
<braunr> antrik: i was meaning sync in the most common meaning, yes, the
client blocking on the reply
@@ -650,6 +650,9 @@ IRC, unknown channel, unknown date:
<braunr> which is why i could choose time_value_t (a struct of 2 integer_t)
<youpi> well, I'd say gnumach could grow a nanosecond-precision time value
<youpi> e.g. for clock_gettime precision and such
+
+[[clock_gettime]].
+
<braunr> so you would prefer me adding the time_spec_t time to gnumach
rather than the hurd ?
<youpi> well, if hurd RPCs are using mach types and there's no mach type
@@ -782,7 +785,7 @@ IRC, unknown channel, unknown date:
API definition at RPC level too
-## IRC, freenode, #hurd, 2012-07-24
+#### IRC, freenode, #hurd, 2012-07-24
<braunr> youpi: antrik: is vm_size_t an appropriate type for a c long ?
<braunr> (appropriate mig type)
@@ -809,7 +812,7 @@ IRC, unknown channel, unknown date:
continue
-## IRC, freenode, #hurd, 2012-07-25
+#### IRC, freenode, #hurd, 2012-07-25
<antrik_> braunr: well, for actual kernel calls, machine-specific types are
probably hard to avoid... the problem is when they are used in other RPCs
@@ -900,7 +903,7 @@ IRC, unknown channel, unknown date:
<braunr> antrik: ah about that, ok
-## IRC, freenode, #hurd, 2012-07-26
+#### IRC, freenode, #hurd, 2012-07-26
<pinotree> braunr: wrt your select_timeout branch, why not push only the
time_data stuff to master?
@@ -914,7 +917,7 @@ IRC, unknown channel, unknown date:
<braunr> i "only" have to adjust the client side select implementation now
-## IRC, freenode, #hurd, 2012-07-27
+#### IRC, freenode, #hurd, 2012-07-27
<braunr> io_select should remain a routine (i.e. synchronous) for server
side stub code
@@ -922,7 +925,14 @@ IRC, unknown channel, unknown date:
<braunr> (since _hurs_select manually handles replies through a port set)
-## IRC, freenode, #hurd, 2012-07-28
+##### IRC, freenode, #hurd, 2013-02-09
+
+ <braunr> io_select becomes a simpleroutine, except inside the hurd, where
+ it's a routine to keep the receive and reply mig stub code
+ <braunr> (the server side)
+
+
+#### IRC, freenode, #hurd, 2012-07-28
<braunr> why are there both REPLY_PORTS and IO_SELECT_REPLY_PORT macros in
the hurd ..
@@ -941,7 +951,7 @@ IRC, unknown channel, unknown date:
<braunr> i did something a bit ugly but it seems to do what i wanted
-## IRC, freenode, #hurd, 2012-07-29
+#### IRC, freenode, #hurd, 2012-07-29
<braunr> good, i have a working client-side select
<braunr> now i need to fix the servers a bit :x
@@ -998,7 +1008,7 @@ IRC, unknown channel, unknown date:
queue ...
-## IRC, freenode, #hurd, 2012-07-30
+#### IRC, freenode, #hurd, 2012-07-30
<braunr> hm nice, the problem i have with my hurd_condition_timedwait seems
to also exist in libpthread
@@ -1096,7 +1106,7 @@ IRC, unknown channel, unknown date:
(http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?h=rbraun/select_timeout&id=40fe717ba9093c0c893d9ea44673e46a6f9e0c7d)
-## IRC, freenode, #hurd, 2012-08-01
+#### IRC, freenode, #hurd, 2012-08-01
<braunr> damn, i can't manage to make threads calling condition_wait to
dequeue themselves from the condition queue :(
@@ -1132,7 +1142,7 @@ IRC, unknown channel, unknown date:
<braunr> it frightens me because i don't see any flaw in the logic :(
-## IRC, freenode, #hurd, 2012-08-02
+#### IRC, freenode, #hurd, 2012-08-02
<braunr> ah, seems i found a reliable workaround to my deadlock issue, and
more than a workaround, it should increase efficiency by reducing
@@ -1150,7 +1160,7 @@ IRC, unknown channel, unknown date:
(/etc/hurd/runsystem i assume)
-## IRC, freenode, #hurd, 2012-08-03
+#### IRC, freenode, #hurd, 2012-08-03
<braunr> glibc actually makes some direct use of cthreads condition
variables
@@ -1302,7 +1312,7 @@ IRC, unknown channel, unknown date:
<braunr> tests, reviews, more tests, polishing, commits, packaging
-## IRC, freenode, #hurd, 2012-08-04
+#### IRC, freenode, #hurd, 2012-08-04
<braunr> grmbl, apt-get fails on select in my subhurd with the updated
glibc
@@ -1324,7 +1334,7 @@ IRC, unknown channel, unknown date:
and thomas d
-## IRC, freenode, #hurd, 2012-08-05
+#### IRC, freenode, #hurd, 2012-08-05
<braunr> eh, i made dpkg-buildpackage use the patched c library, and it
finished the build oO
@@ -1352,7 +1362,7 @@ IRC, unknown channel, unknown date:
extremely large
-## IRC, freenode, #hurd, 2012-08-06
+#### IRC, freenode, #hurd, 2012-08-06
<braunr> i have bad news :( it seems there can be memory corruptions with
my io_select patch
@@ -1395,7 +1405,7 @@ IRC, unknown channel, unknown date:
[[libpthread]].
-## IRC, freenode, #hurd, 2012-08-07
+#### IRC, freenode, #hurd, 2012-08-07
<rbraun_hurd> anyone knows of applications extensively using non-blocking
networking functions ?
@@ -1470,7 +1480,7 @@ IRC, unknown channel, unknown date:
other for the servers, eh)
-## IRC, freenode, #hurd, 2012-08-07
+#### IRC, freenode, #hurd, 2012-08-07
<braunr> when running gitk on [darnassus], yesterday, i could push the CPU
to 100% by simply moving the mouse in the window :p
@@ -1490,7 +1500,7 @@ IRC, unknown channel, unknown date:
<rbraunh> this linear search on dequeue is a real pain :/
-## IRC, freenode, #hurd, 2012-08-09
+#### IRC, freenode, #hurd, 2012-08-09
`screen` doesn't close a window/hangs after exiting the shell.
@@ -1503,7 +1513,7 @@ IRC, unknown channel, unknown date:
[[Term_blocking]].
-# IRC, freenode, #hurd, 2012-12-05
+### IRC, freenode, #hurd, 2012-12-05
<braunr> well if i'm unable to build my own packages, i'll send you the one
line patch i wrote that fixes select/poll for the case where there is
@@ -1512,7 +1522,7 @@ IRC, unknown channel, unknown date:
timeout, doubling the total wait time when there is no event)
-## IRC, freenode, #hurd, 2012-12-06
+#### IRC, freenode, #hurd, 2012-12-06
<braunr> damn, my eglibc patch breaks select :x
<braunr> i guess i'll just simplify the code by using the same path for
@@ -1546,12 +1556,12 @@ IRC, unknown channel, unknown date:
<braunr> this can account for the slowness of a bunch of select/poll users
-## IRC, freenode, #hurd, 2012-12-07
+#### IRC, freenode, #hurd, 2012-12-07
<braunr> finally, my select patch works :)
-## IRC, freenode, #hurd, 2012-12-08
+#### IRC, freenode, #hurd, 2012-12-08
<braunr> for those interested, i pushed my eglibc packages that include
this little select/poll timeout fix on my debian repository
@@ -1560,7 +1570,7 @@ IRC, unknown channel, unknown date:
regressions
-## IRC, freenode, #hurd, 2012-12-10
+#### IRC, freenode, #hurd, 2012-12-10
<gnu_srs> I have verified your double timeout bug in hurdselect.c.
<gnu_srs> Since I'm also working on hurdselect I have a few questions
@@ -1631,7 +1641,13 @@ IRC, unknown channel, unknown date:
<braunr> i'll try the non intrusive mode
-## IRC, freenode, #hurd, 2012-12-11
+##### IRC, freenode, #hurd, 2013-01-26
+
+ <braunr> ah great, one of the recent fixes (probably select-eintr or
+ setitimer) fixed exim4 :)
+
+
+#### IRC, freenode, #hurd, 2012-12-11
<gnu_srs1> braunr: What is the technical difference of having the delay at
io_select compared to mach_msg for one FD?
@@ -1641,7 +1657,7 @@ IRC, unknown channel, unknown date:
<braunr> (for L4 guys it wouldn't be considered a slight optimization :))
-## IRC, freenode, #hurd, 2012-12-17
+#### IRC, freenode, #hurd, 2012-12-17
<braunr> tschwinge:
http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
@@ -1668,20 +1684,20 @@ IRC, unknown channel, unknown date:
notifications resulting from the way io_select works
-## IRC, freenode, #hurd, 2012-12-19
+#### IRC, freenode, #hurd, 2012-12-19
<braunr> tschwinge: i've tested the glibc rbraun/select_timeout_for_one_fd
branch for a few days on darnassus now, and nothing wrong to report
-## IRC, freenode, #hurd, 2012-12-20
+#### IRC, freenode, #hurd, 2012-12-20
<youpi> braunr: so, shall I commit the single hurd select timeout fix to
the debian package?
<braunr> youpi: i'd say so yes
-## IRC, freenode, #hurd, 2013-01-03
+#### IRC, freenode, #hurd, 2013-01-03
<braunr> gnu_srs: sorry, i don't understand your poll_timeout patch
<braunr> it basically reverts mine for poll only
@@ -1848,7 +1864,7 @@ IRC, unknown channel, unknown date:
to the poll stuff: Have to check further with my poll patch...
-## IRC, freenode, #hurd, 2013-01-04
+#### IRC, freenode, #hurd, 2013-01-04
<gnu_srs> Summary of the eglibc-2.13-38 issues: without the
unsubmitted-setitimer_fix.diff patch and with
@@ -2037,6 +2053,388 @@ IRC, unknown channel, unknown date:
See also [[alarm_setitimer]].
+#### IRC, freenode, #hurd, 2013-01-22
+
+ <gnu_srs> youpi: Maybe it's overkill to have a separate case for DELAY; but
+ it enhances readability (and simplifies a lot too)
+ <youpi> but it reduces factorization
+ <youpi> if select is already supposed to behave the same way as delay,
+ there is no need for a separate code
+ <gnu_srs> OK; I'll make a two-way split then. What about POLL and nfds=0,
+ timeout !=0?
+ <braunr> gnu_srs: handle nfds=0 as a pure timeout as the linux man page
+ describes
+ <braunr> it makes sense, and as other popular systems do it, it's better to
+ do it the same way
+ <braunr> and i disagree with you, factorization doesn't imply less
+ readability
+ <gnu_srs> So you agree with me to have a special case for DELAY?
+ <gnu_srs> Coding style is a matter of taste: for me case a: case b: etc is
+ more readable than "if then elseif then else ..."
+ <braunr> it's not coding style
+ <braunr> avoiding duplication is almost always best
+ <braunr> whatever the style
+ <braunr> i don't see the need for a special delay case
+ <braunr> it's the same mach_msg call
+ <braunr> (for now)
+ <braunr> gnu_srs: i'd say the only reason to duplicate is when you can't do
+ otherwise
+ <gnu_srs> ways of coding then... And I agree with the idea of avoiding code
+ duplication, ever heard of Literate Programming
+ <braunr> we'll need a "special case" when the timeout is handled at the
+ server side, but it's like two lines ..
+
+
+#### IRC, freenode, #hurd, 2013-02-11
+
+ <youpi> braunr: the libpthread hurd_cond_timedwait_np looks good to me
+
+
+##### IRC, freenode, #hurd, 2013-02-15
+
+ <youpi> braunr: does cond_timedwait_np depend on the cancellation fix?
+ <braunr> yes
+ <youpi> ok
+ <braunr> the timeout fix
+ <youpi> so I also have to pull that into my glibc build
+ <braunr> (i fixed cancellation too because the cleanup routine had to be
+ adjusted anyway
+ <braunr> )
+ <youpi> ah, and I need the patches hurd package too
+ <braunr> if unsure, you can check my packages
+ <youpi> ok, not for tonight then
+ <braunr> i listed the additional patches in the changelog
+ <youpi> yep, I'll probably use them
+
+
+#### IRC, freenode, #hurd, 2013-02-11
+
+ <youpi> braunr: I don't understand one change in glibc:
+ <youpi> - err = __io_select (d[i].io_port, d[i].reply_port, 0, &type);
+ <youpi> + err = __io_select (d[i].io_port, d[i].reply_port, type);
+ <braunr> youpi: the waittime parameter ahs been removed
+ <braunr> has*
+ <youpi> where? when?
+ <braunr> in the hurd branch
+ <youpi> in the defs?
+ <braunr> yes
+ <youpi> I don't see this change
+ <youpi> only the addition of io_select_timeout
+ <braunr> hum
+ <youpi> also, io_select_timeout should be documented along io_select in
+ hurd.texi
+ <braunr> be6e5b86bdb9055b01ab929cb6b6eec49521ef93
+ <braunr> Selectively compile io_select{,_timeout} as a routine
+ <braunr> * hurd/io.defs (io_select_timeout): Declare as a routine if
+ <braunr> _HURD_IO_SELECT_ROUTINE is defined, or a simpleroutine
+ otherwise.
+ <braunr> (io_select): Likewise. In addition, remove the waittime
+ timeout parameter.
+ <youpi> ah, it's in another commit
+ <braunr> yes, perhaps misplaced
+ <braunr> that's the kind of thing i want to polish
+ <braunr> my main issue currently is that time_data_t is passed by value
+ <braunr> i'm trying to pass it by address
+ <youpi> I don't know the details of routine vs simpleroutine
+ <braunr> it made sense for me to remove the waittime parameter at the same
+ time as adding the _HURD_IO_SELECT_ROUTINE macro, since waittime is what
+ allows glibc to use a synchronous RPC in an asynchronous way
+ <youpi> is it only a matter of timeout parameter?
+ <braunr> simpleroutine sends a message
+ <braunr> routine sends and receives
+ <braunr> by having a waittime parameter, _hurd_select could make io_select
+ send a message and return before having a reply
+ <youpi> ah, that's why in glibc you replaced MACH_RCV_TIMED_OUT by 0
+ <braunr> yes
+ <youpi> it seems a bit odd to have a two-face call
+ <braunr> it is
+ <youpi> can't we just keep it as such?
+ <braunr> no
+ <youpi> damn
+ <braunr> well we could, but it really wouldn't make any sense
+ <youpi> why not?
+ <braunr> because the way select is implemented implies io_select doesn't
+ expect a reply
+ <braunr> (except for the single df case but that's an optimization)
+ <braunr> fd*
+ <youpi> that's how it is already, yes?
+ <braunr> yes
+ <braunr> well yes and no
+ <braunr> that's complicated :)
+ <braunr> there are two passes
+ <braunr> let me check before saying anything ;p
+ <youpi> :)
+ <youpi> in the io_select(timeout=0) case, can it ever happen that we
+ receive an answer?
+ <braunr> i don't think it is
+ <braunr> you mean non blocking right ?
+ <braunr> not infinite timeout
+ <youpi> I mean calling io_select with the timeout parameter being set to 0
+ <braunr> so yes, non blocking
+ <braunr> no, i think we always get MACH_RCV_TIMED_OUT
+ <youpi> for me non-blocking can mean a lot of things :)
+ <braunr> ok
+ <braunr> i was thinking mach_msg here
+ <braunr> ok so, let's not consider the single fd case
+ <braunr> the first pass simply calls io_select with a timeout 0 to send
+ messages
+ <youpi> I don't think it's useful to try to optimize it
+ <youpi> it'd only lead to bugs :)
+ <braunr> me neither
+ <braunr> yes
+ <youpi> (as was shown :) )
+ <braunr> what seems useful to me however is to optimize the io_select call
+ <braunr> with a waittime parameter, the generated code is an RPC (send |
+ receive)
+ <braunr> whereas, as a simpleroutine, it becomes a simple send
+ <youpi> ok
+ <youpi> my concern is that, as you change it, you change the API of the
+ __io_select() function
+ <youpi> (from libhurduser)
+ <braunr> yes but glibc is the only user
+ <braunr> and actually no
+ <braunr> i mean
+ <braunr> i change the api at the client side only
+ <youpi> that's what I mean
+ <braunr> remember that io.Defs is almost full
+ <youpi> "full" ?
+ <braunr> i'm almost certain it becomes full with io_select_timeout
+ <braunr> there is a practical limit of 100 calls per interface iirc
+ <braunr> since the reply identifiers are request + 100
+ <youpi> are we at it already?
+ <braunr> i remember i had problems with it so probably
+ <youpi> but anyway, I'm not thinking about introducing yet another RPC
+ <youpi> but get a reasonable state of io_select
+ <braunr> i'l have to check that limit
+ <braunr> it looks wrong now
+ <braunr> or was it 50
+ <braunr> i don't remember :/
+ <braunr> i understand
+ <braunr> but what i can guarantee is that, while the api changes at the
+ client side, it doesn't at the server side
+ <youpi> ideally, the client api of io_select could be left as it is, and
+ libc use it as a simpleroutine
+ <youpi> sure, I understand that
+ <braunr> which means glibc, whether patched or not, still works fine with
+ that call
+ <braunr> yes it could
+ <braunr> that's merely a performance optimization
+ <youpi> my concern is that an API depends on the presence of
+ _HURD_IO_SELECT_ROUTINE, and backward compatibility being brought by
+ defining it! :)
+ <braunr> yes
+ <braunr> i personally don't mind much
+ <youpi> I'd rather avoid the clutter
+ <braunr> what do you mean ?
+ <youpi> anything that avoids this situation
+ <youpi> like just using timeout = 0
+ <braunr> well, in that case, we'll have both a useless timeout at the
+ client side
+ <braunr> and another call for truely passing a timeout
+ <braunr> that's also weird
+ <youpi> how so a useless timeout at the client side?
+ <braunr> 22:39 < youpi> - err = __io_select (d[i].io_port, d[i].reply_port,
+ 0, &type);
+ <braunr> 0 here is the waittime parameter
+ <youpi> that's a 0-timeout
+ <braunr> and it will have to be 0
+ <youpi> yes
+ <braunr> that's confusing
+ <youpi> ah, you mean the two io_select calls?
+ <braunr> yes
+ <youpi> but isn't that necessary for the several-fd case, anyway?
+ <braunr> ?
+ <braunr> if the io_select calls are simple routines, this useless waittime
+ parameter can just be omitted like i did
+ <youpi> don't we *have* to make several calls when we select on several
+ fds?
+ <braunr> suure but i don't see how it's related
+ <youpi> well then I don't see what optimization you are doing then
+ <youpi> except dropping a parameter
+ <youpi> which does not bring much to my standard :)
+ <braunr> a simpleroutine makes mach_msg take a much shorter path
+ <youpi> that the 0-timeout doesn't take?
+ <braunr> yes
+ <braunr> it's a send | receive
+ <youpi> ok, but that's why I asked before
+ <braunr> so there are a bunch of additional checks until the timeout is
+ handled
+ <youpi> whether timeout=0 means we can't get a receive
+ <youpi> and thus the kernel could optimize
+ <braunr> that's not the same thing :)
+ <youpi> ok
+ <braunr> it's a longer path to the same result
+ <youpi> I'd really rather see glibc building its own private simpleroutine
+ version of io_select
+ <youpi> iirc we already have such kind of thing
+ <braunr> ok
+ <braunr> well there are io_request and io_reply defs
+ <braunr> but i haven't seen them used anywhere
+ <braunr> but agreed, we should do that
+ <youpi> braunr: the prototype for io_select seems bogus in the io_request,
+ id_tag is no more since ages :)
+ <braunr> youpi: yes
+ <braunr> youpi: i'll recreate my hurd branch with only one commit
+ <braunr> without the routine/simpleroutine hack
+ <braunr> and with time_data_t passed by address
+ <braunr> and perhaps other very minor changes
+ <youpi> braunr: the firstfd == -1 test needs a comment
+ <braunr> or better, i'll create a v2 branch to make it easy to compare them
+ <braunr> ok
+ <youpi> braunr: actually it's also the other branch of the if which needs a
+ comment: "we rely on servers implementing the timeout"
+ <braunr> youpi: ok
+ <youpi> - (msg.success.result & SELECT_ALL) == 0)
+ <youpi> why removing that test?
+ <youpi> you also need to document the difference between got and ready
+ <braunr> hm i'll have to remember
+ <braunr> i wrote this code like a year ago :)
+ <braunr> almost
+ <youpi> AIUI, got is the number of replies
+ <braunr> but i think it has to do with error handling
+ <braunr> and
+ <braunr> + if (d[i].type)
+ <braunr> + ++ready;
+ <youpi> while ready is the number of successful replies
+ <braunr> is what replaces it
+ <braunr> youpi: yes
+ <braunr> the poll wrapper already normalizes the timeout parameter to
+ _hurd_select
+ <braunr> no you probably don't
+ <braunr> the whole point of the patch is to remove this ugly hack
+ <braunr> youpi: ok so
+ <braunr> 23:24 < youpi> - (msg.success.result & SELECT_ALL)
+ == 0)
+ <braunr> when a request times out
+ <youpi> ah, right
+ <braunr> we could get a result with no event
+ <braunr> and no error
+ <braunr> and this is what makes got != ready
+ <youpi> tell that to the source, not me :)
+ <braunr> sure :)
+ <braunr> i'm also saying it to myself
+ <braunr> ... :)
+ <youpi> right, using io_select_request() is only an optimization, which we
+ can do later
+ <braunr> what i currently do is remove the waittime parameter from
+ io_select
+ <braunr> what we'll do instead (soon) is let the parameter there to keep
+ the API unchancged
+ <braunr> but always use a waittime of 0
+ <braunr> to make the mach_msg call non blocking
+ <braunr> then we'll try to get the io_request/io_reply definitions back so
+ we can have simpleroutines (send only) version of the io RPCs
+ <braunr> and we'll use io_select_request (without a waittime)
+ <braunr> youpi: is that what you understood too ?
+ <youpi> yes
+ <youpi> (and we can do that later)
+ <braunr> gnu_srs: does it make more sense for you ?
+ <braunr> this change is quite sparsed so it's not easy to get the big
+ picture
+ <braunr> sparse*
+ <braunr> it requires changes in libpthread, the hurd, and glibc
+ <youpi> the libpthread change can be almost forgotten
+ <youpi> it's just yet another cond_foo function :)
+ <braunr> well not if he's building his own packages
+ <youpi> right
+ <youpi> ok, apart from the io_select_request() and documenting the newer
+ io_select_timeout(), the changes seem good to me
+ <braunr> youpi: actually, a send | timeout takes the slow path in mach_msg
+ <braunr> and i actually wonder if send | receive | timeout = 0 can get a
+ valid reply from the server
+ <braunr> but the select code already handles that so it shouldn't be much
+ of a problem
+ <youpi> k
+
+
+##### IRC, freenode, #hurd, 2013-02-12
+
+ <braunr> hum
+ <braunr> io_select_timeout actually has to be a simpleroutine at the client
+ side :/
+ <braunr> grmbl
+ <youpi> ah?
+ <braunr> otherwise it blocks
+ <youpi> how so?
+ <braunr> routines wait for replies
+ <youpi> even with timeout 0?
+ <braunr> there is no waittime for io_select_timeout
+ <braunr> adding one would be really weird
+ <youpi> oh, sorry, I thought you were talking about io_select
+ <braunr> it would be more interesting to directly use
+ io_select_timeout_request
+ <braunr> but this means additional and separate work to make the
+ request/reply defs up to date
+ <braunr> and used
+ <braunr> personally i don't mind, but it matters for wheezy
+ <braunr> youpi: i suppose it's not difficult to add .defs to glibc, is it ?
+ <braunr> i mean, make glibc build the stub code
+ <youpi> it's probably not difficult indeed
+ <braunr> ok then it's better to do that first
+ <youpi> yes
+ <youpi> there's faultexec for instance in hurd/Makefile
+ <braunr> ok
+ <youpi> or rather, apparently it'd be simply user-interfaces
+ <youpi> it'll probably be linked into libhurduser
+ <youpi> but with an odd-enough name it shouldn't matter
+ <braunr> youpi: adding io_request to the list does indeed build the RPCs :)
+ <braunr> i'll write a patch to sync io/io_reply/io_request
+ <braunr> youpi: oh by the way, i'm having a small issue with the
+ io_{reply,request} interfaces
+ <braunr> the generated headers both share the same enclosing macro
+ (_io_user)
+ <braunr> so i'm getting compiler warning
+ <braunr> s
+ <youpi> we could fix that quickly in mig, couldn't we?
+ <braunr> youpi: i suppose, yes, just mentioning
+
+
+##### IRC, freenode, #hurd, 2013-02-19
+
+ <youpi> in the hurdselect.c code, I'd rather see it td[0]. rather than
+ td->
+ <braunr> ok
+ <youpi> otherwise it's frownprone
+ <youpi> (it has just made me frown :) )
+ <braunr> yes, that looked odd to me too, but at the same time, i didn't
+ want it to seem to contain several elements
+ <youpi> I prefer it to look like there could be several elements (and then
+ the reader has to find out how many, i.e. 1), rather than it to look like
+ the pointer is not initialized
+ <braunr> right
+ <youpi> I'll also rather move that code further
+ <youpi> so the preparation can set timeout to 0
+ <youpi> (needed for poll)
+ <youpi> how about turning your branch into a tg branch?
+ <braunr> feel free to add your modifications on top of it
+ <braunr> sure
+ <youpi> ok
+ <youpi> I'll handle these then
+ <braunr> youpi: i made an updated changelog entry in the
+ io_select_timeout_v3 branch
+ <youpi> could you rather commit that to the t/io_select_timeout branch I've
+ just created?
+ <braunr> i mean, i did that a few days ago
+ <youpi> (in the .topmsg file)
+ <youpi> ah
+ <youpi> k
+
+
+##### IRC, freenode, #hurd, 2013-02-26
+
+ <braunr> youpi: i've just pushed a rbraun/select_timeout_pthread_v4 branch
+ in the hurd repository that includes the changes we discussed yesterday
+ <braunr> untested, but easy to compare with the previous version
+
+
+##### IRC, freenode, #hurd, 2013-02-27
+
+ <youpi> braunr: io_select_timeout seems to be working fine here
+ <youpi> braunr: I feel like uploading them to debian-ports, what do you
+ think?
+ <braunr> youpi: the packages i rebuild last night work fine too
+
+
# See Also
See also [[select_bogus_fd]] and [[select_vs_signals]].
diff --git a/open_issues/select_vs_signals.mdwn b/open_issues/select_vs_signals.mdwn
index 9e9699b8..db616acb 100644
--- a/open_issues/select_vs_signals.mdwn
+++ b/open_issues/select_vs_signals.mdwn
@@ -42,6 +42,21 @@ In context of [[alarm_setitimer]].
Proposed patch: [[!message-id
"20130105162817.GW5965@type.youpi.perso.aquilenet.fr"]].
+
+## IRC, freenode, #hurd, 2013-01-15
+
+ <_d3f> Hello, any one else having problems with git?
+ <braunr> _d3f: yes
+ <braunr> _d3f: it will be fixed in the next glibc release
+ <_d3f> oh thx. what was the problem?
+ <braunr> http://lists.gnu.org/archive/html/bug-hurd/2013-01/msg00005.html
+ <WhiteKIBA> exactly this problem is preventing us building glibc
+ <braunr> it's indeed very annoying
+ <braunr> and this fix will probably have a visible and positive effect on
+ other issues
+ <_d3f> let's hope so.
+ <braunr> well, i'm already using it and see the difference
+
---
See also [[select]] and [[select_bogus_fd]].
diff --git a/open_issues/some_todo_list.mdwn b/open_issues/some_todo_list.mdwn
index 82822a29..80592abf 100644
--- a/open_issues/some_todo_list.mdwn
+++ b/open_issues/some_todo_list.mdwn
@@ -27,7 +27,6 @@ From Marcus, 2002:
* xkb driver for console (for international users)
* kbd leds in console (well, in general, Roland's new driver in oskit for that crap)
-* fixing fakeroot (it's buggy)
* fixing tmpfs (it's buggy, Neal says it's Mach's fault)
* adding posix shared memory (requires the io\_close call to be implemented)
* adding posix file locking (requires the io\_close call to be implemented)
diff --git a/open_issues/subhurd_vs_proc_server.mdwn b/open_issues/subhurd_vs_proc_server.mdwn
new file mode 100644
index 00000000..36d150f8
--- /dev/null
+++ b/open_issues/subhurd_vs_proc_server.mdwn
@@ -0,0 +1,54 @@
+[[!meta copyright="Copyright © 2013 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_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-02-09
+
+ <youpi> also, can you actually gdb a process of another subhurd?
+ <braunr> yes
+ <youpi> but you need to talk to its proc server, don't you?
+ <braunr> i don't know
+ <braunr> but i did it several times
+ <youpi> how?
+ <braunr> the usual way
+ <braunr> gdb /path/to/bin pid
+ <youpi> but which pid?
+ <braunr> the hard part was finding the right pid
+ <youpi> well, gdb still needs to talk with the right proc too
+ <braunr> i don't think it does
+ <youpi> btw about the "unable to adjust libports thread priority" errors
+ I'm seeing on the buildd consoles
+ <braunr> from what i've seen, proc "creates" tasks when it first sees them
+ too
+ <youpi> it's about the destination port
+ <braunr> yes
+ <braunr> i have those when starting a subhurd too
+ <youpi> so it would mean that proc somehow got bogus
+ <youpi> ah
+ <youpi> so you can actually use your own proc
+ <braunr> yes
+ <braunr> and it feels bogus to me
+ <youpi> and I guess mach lets that proc access the task because your proc
+ is privileged
+ <braunr> probably
+ <braunr> it feels bogus because, you can't rely on pids being allocated per
+ task
+ <braunr> what i mean is that, if some tasks spawn and die quickly
+ <braunr> and you start another application running long enough to see it in
+ ps
+ <braunr> it's pid will be +1, not +the number of created tasks
+ <braunr> which means the proc server will never have seen those previous
+ tasks
+ <braunr> it's minor but a bit confusing
+ <braunr> i personally don't like seeing the tasks of other systems in ps :/
+ <braunr> and despite the ability to use gdb from another hurd, i think we
+ should improve the intra system debugging tools
diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn
index 19cba82e..ab32b2e1 100644
--- a/open_issues/syslog.mdwn
+++ b/open_issues/syslog.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -13,6 +13,7 @@ License|/fdl]]."]]"""]]
[[!toc]]
+
# IRC, unknown channel, unknown date
<tschwinge> scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725
@@ -105,3 +106,11 @@ IRC, OFTC, #debian-hurd, 2011-11-02:
<antrik> it depends on how many things are actually logged. IIRC the hang
happens when some client sends 128 messages to syslog or something like
that
+
+
+# IRC, freenode, #hurd, 2013-02-09
+
+ <pinotree> tschwinge: looks like now you could disable syslog no
+ <pinotree> ... more
+ <tschwinge> It that working now?
+ <pinotree> should be yes, samuel fixed its issue many months ago
diff --git a/open_issues/system_stats.mdwn b/open_issues/system_stats.mdwn
index 9a13b29a..ce34ec09 100644
--- a/open_issues/system_stats.mdwn
+++ b/open_issues/system_stats.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -37,3 +37,9 @@ system statistics, how to interpret them, and some example/expected values.
<mcsim> yes
<braunr> (a test that fails with the 2G/2G split of the debian kernel, but
not on your vanilla version btw)
+
+
+## IRC, frenode, #hurd, 2013-01-26
+
+ <braunr> ah great, one of the recent fixes (probably select-eintr or
+ setitimer) fixed exim4 :)
diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn
index 1d774307..c23f887f 100644
--- a/open_issues/systemd.mdwn
+++ b/open_issues/systemd.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2013 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
@@ -92,7 +93,16 @@ Likely there's also some other porting needed.
<pochu> agreed
-# Requires Interfaces
+## IRC, freenode, #hurd, 2013-01-18
+
+ <braunr> systemd relies on linux specific stuff that is difficult to
+ implement
+ <braunr> notably cgroups to isolate the deamons it starts so it knows when
+ they stopped regardless of their pid
+ <braunr> just assume you can't use systemd on anything else than linux
+
+
+# Required Interfaces
In the thread starting
[here](http://lists.debian.org/debian-devel/2011/07/threads.html#00269), a
diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
index 1dac130c..521331e9 100644
--- a/open_issues/translators_set_up_by_untrusted_users.mdwn
+++ b/open_issues/translators_set_up_by_untrusted_users.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 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
@@ -350,3 +350,230 @@ IRC, freenode, #hurd, 2011-09-14:
<antrik> cjuner: either glibc or the parent translators
Continued discussion about [[resource_management_problems/pagers]].
+
+
+# IRC, freenode, #hurd, 2013-02-24
+
+ <braunr> on a more general topic, i've been thinking about client and
+ server trust
+ <braunr> there have been many talkbs about it regarding l4/coyotos/hurdng
+ <youpi> I generally think the client can trust the server
+ <braunr> and passing the select timeout to servers corroborates this
+ <youpi> because it's either root, or it's the same user
+ <braunr> hum yes, but that's not exactly my question, you'll see
+ <braunr> there is one feature the hurd has, and i'm not sure we should have
+ it considering what it requires
+ <braunr> the feature is that clients can, at any time, "break" from a
+ server
+ <youpi> "break" ?
+ <braunr> the current implementation is to cancel the current RPC after 3
+ seconds without a reply when the user sends SIGINT
+ <braunr> the problem is that, moving to a complete migrating thread model
+ would make that impossible (or very complicated to do right)
+
+[[mach_migrating_threads]].
+
+ <braunr> would it be ok to remove this feature ?
+ <youpi> well, we need to have SIGINT working, don't we?
+ <braunr> obviously
+ <braunr> but that's not what the feature is meant to do
+ <braunr> it allows clients to recover from a server that misbehaves and
+ doesn't return
+ <youpi> then I don't understand in enough details what you mean :)
+ <braunr> imagine a buggy driver in linux that gets into an uninterruptible
+ sleep
+ <braunr> you can't even kill your process
+ <braunr> that's what the feature is meant to solve
+ <youpi> that's a quite useful thing
+ <youpi> e.g. stuck nfs etc., it's useful to be able to recover from that
+ <braunr> forbidding uninterruptible sleeps would also be a solution, but
+ then it means relying on servers acting right
+ <braunr> which is why i mention we usually trust servers
+ <youpi> well, there is "trust" and "trust" :)
+ <youpi> i.e. security-wise and robustness-wise
+ <youpi> I meant clients can usually trust servers security-wise
+ <braunr> my current idea for x15 is to forbid this kind of breaking, but
+ also forbid uninterruptible sleeps
+ <youpi> robustness-wise, I'd say no
+ <braunr> this way, sending a signal directly reaches the server, which is
+ trusted to return right away (well, conforming to the handling behaviour)
+ <braunr> so yes, buggy servers would prevent that, but on the other hand,
+ stuck nfs wouldn't
+ <youpi> provided the nfs implementation is not bogus
+ <braunr> yes
+ <youpi> I'd tend to agree, but would rather see this discussed on the list
+ <braunr> yes
+ <braunr> actually, it wouldn't be that hard to keep the current behaviour,
+ since i won't implement true migrating threads
+ <braunr> but it means retaining some issues we have (most importantely,
+ denial of service)
+ <braunr> -e
+ <braunr> what i want to avoid is
+ http://www.gnu.org/software/hurd/hurd/ng/cancellationforwarding.html
+ <youpi> for non-trusted servers, we could have a safety wrapper
+ <youpi> which we trust and does things carefully when talking with the
+ non-trusted server
+ <braunr> what would a non trusted server be ?
+ <youpi> whatever is neither root nor me
+ <youpi> e.g. nobody-provided /ftp:, or $HOME of another user, etc.
+ <braunr> i'd argue we don't talk to non trusted servers at all, period
+ <youpi> users won't like it :)
+ <braunr> and i'd extend root to a system provided list
+ <youpi> actually the nobody /ftp: case is important
+ <braunr> users should be able to create their own list of trusted users
+ <youpi> it's also the nobody /dev/null case
+ <youpi> atm it's root
+ <braunr> yes
+ <braunr> i see the point
+ <braunr> i'm just saying the idea of "using non-trusted server" doesn't
+ make sense
+ <youpi> actually running /ftp: under nobody is dangerous
+ <youpi> since if you're running as nobody (because you broke into the
+ system or whatever), then you can poke with nobody-provided servers
+ <braunr> yes
+ <youpi> so we'd rather have really-nobody processes
+ <braunr> taht's an already existing problem
+ <youpi> which can't be poked into
+ <youpi> (and thus can't poke into each other)
+ <braunr> or a separate user for each
+ <youpi> that'd be difficult
+ <braunr> or separate tokens, it's not important
+ <youpi> for /ftp:/ftp.debian.org used by someone, and /ftp:/ftp.foo.org
+ used by someone else
+ <braunr> what i mean is that, by talking to a server, a client implicitely
+ trusts it
+ <braunr> youpi: wouldn't that just be the same "ftp" user ?
+ <youpi> ideally, a carefully-crafted client could avoid having to trust it
+ <braunr> really ?
+ <youpi> braunr: that's the problem: then each ftpfs can poke on each other
+ <braunr> well, each global one
+ <youpi> there's the daemon-sharing issue too, yes
+ <braunr> i wasn't thinking about ftpfs, but rather the "system" pfinet for
+ example
+ <youpi> like /dev/null is shared
+ <braunr> when you say root or me, it's "system" or me
+ <braunr> by default, users trust their system
+ <braunr> they don't trust other users
+ <youpi> avoid having to trust it: yes, by using timeouts etc.
+ <braunr> that's clearly not enough
+ <youpi> why?
+ <braunr> shapiro described this in a mail but i can't find it right now
+ <youpi> I wouldn't like to have to trust ftpfs
+ <braunr> well time is one thing, data provided for example is another
+ <braunr> well, you do
+ <youpi> who knows what bug ftpfs has
+ <youpi> ideally I would be able not to have to
+ <youpi> braunr: you can check data
+ <braunr> i don't think that ideal is possible
+ <braunr> it you set a ftp translator with a user account, you give it the
+ password
+ <youpi> which password?
+ <braunr> the account password
+ <youpi> which account?
+ <braunr> "a user account"
+ <braunr> i.e. not anonymoius
+ <youpi> ah
+ <youpi> well, sure, you have to give that to ftpfs
+ <youpi> I mean the ftp server might be malicious or whatever
+ <youpi> and trigger a bug in ftpfs
+ <braunr> yes
+ <youpi> so I don't want to have to trust ftpfs
+ <braunr> what would that mean in practice ?
+ <youpi> have a trusted translation layer which papers over it, checking
+ timeouts & data
+ <braunr> how do you check data ?
+ <youpi> by knowing the protocol
+ <braunr> ?
+ <braunr> can you give a quick example ?
+ <youpi> well, which data check do you need?
+ <youpi> (it's you who mentioned data issues :) )
+ <braunr> i don't know what you mean by that so, choose as you see fit
+ <braunr> well the password one for example
+ <braunr> i was merely saying that, buy using an application, be it a
+ regular one or a translator, you automatically trust it
+ <youpi> you mean the ftp user password ?
+ <braunr> it becomes part of your tcb
+ <youpi> of course you have to provide it to ftpfs
+ <youpi> that's not a problem
+ <youpi> yes, but it's not because you connect to an http website that you
+ trust the webserver on the other end
+ <youpi> your web browser does checking for you
+ <braunr> when the protocol allows it
+ <braunr> (in this case, i'm thinking assymmetrical cryptography)
+ <youpi> in which case example doesn't it ?
+ <youpi> it seems we're not talking about the same kind of issue, thus not
+ understanding each other
+ <braunr> indeed
+ <youpi> by "trusting", I don't mean "be sure that it's the right server at
+ the other end"
+ <braunr> my point is that not trusting a server is impossible
+ <youpi> I mean "it behaves correectly"
+ <braunr> yes
+ <braunr> it may not behave correctly, and we might not know it
+ <youpi> as long as it doesn't make the program crash, that's fine
+ <youpi> that's what I mean
+ <braunr> that's where the difference is
+ <youpi> but giving the password is not my concern here
+ <youpi> and giving the password is a matter of cryptography, etc. yes, but
+ that's completely not my point
+ <braunr> i'm concerned about absolute correct behaviour
+ <braunr> hm
+ <braunr> no actually i was
+ <braunr> but not any more, the discussion has shifted back to the timeout
+ issue
+ <braunr> ah no, i remember
+ <braunr> we talked about which servers to trust
+ <braunr> and how to alter communication accordingly
+ <braunr> and my point was that altering communication shouldn't be done, we
+ either trust the server, and talk to it, or we don't, and we stay away
+ <braunr> the wrapper would help for this specific blocking issue, yes
+ <youpi> I don't agree on this
+ <youpi> let me take a way more simple example
+ <youpi> a server that provides data through io_read
+ <youpi> I don't want to trust it because it's provided by some joe user
+ <youpi> but I still want to have a look at the data that it produces
+ <youpi> I'm fine that the data may be completely non-sense, that's not a
+ problem
+ <youpi> what is a problem, however, is if the hexdump program I've run over
+ it can't be ^C-ed
+ <braunr> yes, that's the specific issue i mentioned
+ <youpi> and for that, a mere trusted intermediate could be enough
+ <braunr> iirc, there is a firmlink-related issue
+ <youpi> ?
+ <braunr>
+ http://www.gnu.org/software/hurd/open_issues/translators_set_up_by_untrusted_users.html
+ <youpi> I'm not able to guess what conclusion you are drawing here :)
+ <braunr> don't talk to untrusted servers
+ <youpi> or be careful
+ <youpi> the rm -fr /tmp being aabout being careful actually
+ <braunr> right
+ <braunr> i have a very unix-centric view for my system actually
+ <braunr> i think posix compatibility is very important for me
+ <braunr> more than it seems to have been in the past when the hurd was
+ designed
+ <braunr> to* me
+ <braunr> so i don't trust tools to be careful
+ <youpi> that's why a wrapping translator could make it back to posix
+ compatibility
+ <braunr> but i see what you mean
+ <youpi> being careful for the tools
+ <braunr> hum, a wrapping _translator_ ?
+ <youpi> yes, similar to remap and fakeroot
+ <braunr> ok
+ <youpi> you'd tell it "for this path, please be careful for my tools"
+ <braunr> ok so
+ <braunr> it would basically still end up trusting system or me
+ <braunr> but you'd add this wrapper to the system
+ <youpi> "it" ?
+ <braunr> the situation
+ <braunr> i don't know :)
+ <braunr> the implementation, whatever
+ <youpi> the shell I'm running, you mean
+ <braunr> and it would be the job of this translator to shield the user
+ <youpi> yes
+ <braunr> that's a good idea, yes
+ <youpi> it could reduce the allowed RPC set to what it knows to check
+ <braunr> how would the shell use it ?
+ <braunr> would it "shadow" / ?
+ <youpi> yes
+ <braunr> ok
diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn
index 10cf73db..34074c18 100644
--- a/open_issues/virtualization.mdwn
+++ b/open_issues/virtualization.mdwn
@@ -46,3 +46,5 @@ An index of things to work on w.r.t. virtualization.
* [[Networking]]
* [[remap_root_translator]]
+
+ * [[fakeroot]]
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
new file mode 100644
index 00000000..ec762b59
--- /dev/null
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -0,0 +1,17 @@
+[[!meta copyright="Copyright © 2010, 2013 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_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-02-26
+
+ <youpi> btw, about fakeroot-hurd
+ <youpi> the remaining issue I see is with argv[0] (yes, again...)
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
index 3cb574ae..67d64ae0 100644
--- a/open_issues/virtualization/remap_root_translator.mdwn
+++ b/open_issues/virtualization/remap_root_translator.mdwn
@@ -95,3 +95,47 @@ License|/fdl]]."]]"""]]
<youpi> his own one
<braunr> ok
<youpi> attached to the remapping
+
+
+## IRC, freenode, #hurd, 2013-01-29
+
+ <youpi> ok, the remap translator was too easy
+ <youpi> just took fakeroot.c
+ <youpi> added if (!strcmp("bin/foo", filename)) filename =
+ "bin/bash"; in
+ <youpi> netfs_S_dir_lookup
+ <youpi> and it just works
+ <youpi> ok, remap does indeed take my own pfinet
+ <youpi> good :)
+ <youpi> pfinet's tun seems to be working too
+ <youpi> it's however not really flexible, it has to show up in /dev/tunx
+ <youpi> I'll have a look at fixing that
+ <youpi> yep, works fine
+
+
+## IRC, freenode, #hurd, 2013-02-01
+
+ <youpi> braunr: as I expected, simply passing FS_RETRY_REAUTH does the
+ remapping trick
+
+
+# IRC, freenode, #hurd, 2013-02-12
+
+ <braunr>
+ http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/server_overriding/
+ <braunr> youpi: isn't that your remap translator ?
+ <youpi> completely
+ <youpi> remap being (5)
+
+
+# IRC, freenode, #hurd, 2013-02-25
+
+ <youpi> I'm just having an issue with getcwd getting in the sky
+ <youpi> I wonder whether libc might need patching to understand it's in
+ some sort of chroot
+ <youpi> or perhaps remap fixed into avoiding .. of / being odd
+ <youpi> erf, it's actually an explicit error
+ <youpi> libc just doesn't want to have a ".." / being different from CRDIR
+ <youpi> let me just comment out that :)
+ <youpi> way better :)
+ <youpi> yep, just works fine
diff --git a/open_issues/vm_map_kernel_bug.mdwn b/open_issues/vm_map_kernel_bug.mdwn
index 613c1317..159e9d04 100644
--- a/open_issues/vm_map_kernel_bug.mdwn
+++ b/open_issues/vm_map_kernel_bug.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 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
@@ -52,3 +52,20 @@ License|/fdl]]."]]"""]]
<braunr> it could be that gnumach isn't good at aligning to large values
[[!message-id "87fw4pb4c7.fsf@kepler.schwinge.homeip.net"]]
+
+
+# IRC, frenode, #hurd, 2013-01-22
+
+In context of [[libpthread]].
+
+ <braunr> pinotree: do you understand what the fmh function does in
+ sysdeps/mach/hurd/dl-sysdep.c ?
+ <braunr> ok i understand what it does
+ <braunr> and youpi has changed the code, so he does too
+ <braunr> youpi: do you have a suggestion about how to solve this issue in
+ the fmh function ?
+ <youpi> do we remember which bug it's after?
+ <braunr> what do you mean ?
+ <braunr> ah
+ <braunr> no :/
+ <braunr> it could be a good occasion to get rid of it, yes