summaryrefslogtreecommitdiff
path: root/open_issues
diff options
context:
space:
mode:
authorThomas Schwinge <thomas@codesourcery.com>2013-04-07 18:28:11 +0200
committerThomas Schwinge <thomas@codesourcery.com>2013-04-07 18:28:11 +0200
commit325d3600adae1a2da62f9a24ac34ad2b47a22f97 (patch)
treef0637c13c8aec0d0793f7d2498f5e2237e693c4b /open_issues
parentacab07dfc9df44d6d54e03c701a90b5d6f537fcd (diff)
parent6c7d45e4631784d0e077e806521a736da6b0266e (diff)
Merge remote-tracking branch 'fp/master'
Conflicts: hurd.mdwn hurd/debugging/rpctrace.mdwn open_issues/clock_gettime.mdwn open_issues/time.mdwn
Diffstat (limited to 'open_issues')
-rw-r--r--open_issues/anatomy_of_a_hurd_system.mdwn29
-rw-r--r--open_issues/clock_gettime.mdwn9
-rw-r--r--open_issues/glibc/debian/experimental.mdwn115
-rw-r--r--open_issues/libpthread.mdwn13
-rw-r--r--open_issues/linux_vmsig.mdwn17
-rw-r--r--open_issues/managed_runtime_initiative.mdwn72
-rw-r--r--open_issues/multithreading.mdwn27
-rw-r--r--open_issues/nice_vs_mach_thread_priorities.mdwn40
-rw-r--r--open_issues/performance/io_system/read-ahead.mdwn42
-rw-r--r--open_issues/pfinet_timers.mdwn102
-rw-r--r--open_issues/translate_fd_or_port_to_file_name.mdwn70
-rw-r--r--open_issues/virtualization/fakeroot.mdwn7
-rw-r--r--open_issues/virtualization/remap_root_translator.mdwn5
13 files changed, 536 insertions, 12 deletions
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index ebb48e24..677e4625 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -351,3 +351,32 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
<braunr>
http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
should be a pretty good list :)
+
+
+# IRC, freenode, #hurd, 2013-03-12
+
+ <mjjc> i have a question regarding ipc in hurd. if a task is created, does
+ it contain any default port rights in its space? i am trying to deduce
+ how one calls dir_lookup() on the root translator in glibc's open().
+ <kilobug> mjjc: yes, there are some default port rights, but I don't
+ remember the details :/
+ <mjjc> kilobug: do you know where i should search for details?
+ <kilobug> mjjc: hum either in the Hurd's hacking guide
+ https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
+ source code of exec server/libc I would say, or just ask again the
+ question here later on to see if someone else has more information
+ <mjjc> ok, thanks
+ <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
+ executed
+ <braunr> some ports are introduced in new tasks, yes
+ <braunr> see
+ http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
+ <braunr> and
+ <braunr>
+ http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
+ <mjjc> yes, the second link was just what i was looking for, thanks
+ <braunr> the second is very general
+ <braunr> also, the first applies to translators only
+ <braunr> if you're looking for how to do it for a non-translator
+ application, the answer is probably somewhere in glibc
+ <braunr> _hurd_startup i'd guess
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 3caa6c28..5ba6b418 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -188,4 +188,13 @@ In context of [[select]].
<youpi> and we'll make that a 64bit struct when we have a64bit userland
+# IRC, freenode, #hurd, 2013-04-06
+
+ <tschwinge> pinotree: You had once been working on adding nsec-procision
+ timestamps to GNU Mach's maptime interface (or what the name is). Is
+ that blocked on something or just waiting to be continued?
+ <pinotree> blocked on me needing to learn more the proper way to do
+ "atomic" update of the struct with time :)
+
+
# Candidate for [[vDSO]] code?
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
new file mode 100644
index 00000000..8d117e99
--- /dev/null
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -0,0 +1,115 @@
+[[!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_glibc]]
+
+Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-14
+
+ <markus_w1nner> I have a strange tcp via localhost question:
+ <markus_wanner> The other side closes the connection, but I haven't read
+ all data, yet. I should still be able to read the pending data, no?
+ <markus_wanner> At least it seems to work that way on Linux, but not on
+ Hurd.
+ <markus_wanner> Got a simple repro with nc, if you're interested...
+ <youpi> markus_wanner: yes, we're interested
+ <markus_wanner> youpi: okay, here we go:
+ <markus_wanner> session 1: nc -l -p 7777 localhost
+ <markus_wanner> session 2: nc 127.0.0.1 7777
+ <markus_wanner> session 2: a <RET> b <RET> c <RET>
+ <markus_wanner> session 1: [ pause with Ctrl-Z ]
+ <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET>
+ <markus_wanner> session 2: [ quit with Ctrl-C ]
+ <markus_wanner> session 1: [ resume with 'fg' ]
+ <markus_wanner> The server on session 1 doesn't get the data sent after it
+ paused and before the client closed the connection.
+ <markus_wanner> I'm not sure if that's a valid TCP thing. However, on
+ Linux, the server still gets the data. On hurd it doesn't.
+ <markus_wanner> I'm working on a C-code test case, ATM.
+ <youpi> markus_wanner: on which box are you seeing this behavior?
+ <youpi> exodar does not have it
+ <youpi> i.e. I do get the d e f
+ <markus_wanner> a private VM (I'm not a DD)
+ <markus_wanner> ..updated to latest experimental stuff.
+ <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU
+ <youpi> ok, I can't reproduce it on my vm either
+ <youpi> maybe the C program will help
+ <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still
+ shows the issue, though).
+ <markus_wanner> I'll try to strace netcat...
+ <markus_wanner> ..Meh. strace not available on Hurd?
+ <pinotree> no, but there is rpctrace to show the various rpc
+ <markus_wanner> Cool, looks helpful.
+ <markus_wanner> Thx
+ <markus_wanner> Uh.. that introduces another error:
+ <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward:
+ Assertion `reply_type == 18' failed.
+
+[[hurd/debugging/rpctrace]].
+
+ <youpi> I'm checking on a box without ipv6 configuration
+ <youpi> maybe that's the difference between you and me
+ <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ?
+ <markus_wanner> Yup, nc.traditional.
+ <markus_wanner> Looks like that box only has IPv4 configured.
+ <markus_wanner> Something very strange is going on here. No matter how hard
+ I try, I cannot reproduce this with netcat, anymore.
+ <pinotree> not even after a reboot?
+ <markus_wanner> Woo.. here, it happened, again! This is driving me crazy!
+ <markus_wanner> Now, nc seemingly connects, but is unable to send data
+ between the two. Netcat would somehow complain, if it failed to connect,
+ no?
+ <markus_wanner> No it worked.
+ <markus_wanner> So this seems to be an intermittent issue. So far, I could
+ only ever repro it as a normal user, not as root. May be coincidental,
+ though.
+ <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent
+ manually just after that. Something with that TCP/IP stack is definitely
+ fishy.
+ <markus_wanner> Anything I can try to investigate? Or shall I simply
+ restart and see if the problem persists?
+ <youpi> maybe restart, yes
+ <youpi> did you restart since the upgrade ?
+ <markus_wanner> Yes, I restarted after that.
+ <markus_wanner> Hm.. okay, restarted. Some problem persists.
+ <markus_wanner> I currently have two netcat processes connected, the
+ listening one got some first two messages and seems stuck now.
+ <markus_wanner> With the client, I tried to send more data, but the server
+ doesn't get it, anymore.
+ <markus_wanner> Any idea on what I can do to analyze the situation?
+ <youpi> for the netcat issue, I haven't experienced this
+ <youpi> are you running in kvm or virtualbox or something else?
+ <markus_wanner> I'm currently puzzled about what "experimental" actually
+ ships.
+ <markus_wanner> On kvm.
+ <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3.
+ <markus_wanner> But packages.d.o already shows 2.17.0experimental2.
+ <youpi> experimental ships experimental versions, which you aren't supposed
+ to use
+ <youpi> unless you know what you are doing
+ <youpi> iirc 2.17 is known to be quite broken for now
+ <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then.
+ <markus_wanner> Phew, okay, successfully downgraded to unstable.
+ <markus_wanner> Hopefully monotone's test suite runs through fine, now.
+ <markus_wanner> Yup, WORKING! Looks like some experimental packages caused
+ the problem. The netcat test as well as that one failing monotone test
+ work fine, now.
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-19
+
+ <tschwinge> pinotree, youpi: Is there anything from that markus_wanner
+ discussion about pfinet/netcat/signals that needs to be filed? I guess
+ we don't know what exactly he changed so that everything workedd fine
+ eventually? (Some experimental package(s), but which?)
+ <youpi> that was libc0.3 packages
+ <youpi> which are indeed known to break the network
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index d0ec4119..28532320 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1281,6 +1281,19 @@ Most of the issues raised on this page has been resolved, a few remain.
<braunr> weird sentence, agreed :p
+### IRC, freenode, #hurd, 2013-03-11
+
+ <braunr> youpi: oh btw, i noticed a problem with the priority adjustement
+ code
+ <braunr> a thread created by a privileged server (e.g. an ext2fs
+ translator) can then spawn a server from a node owned by an unprivileged
+ user
+ <braunr> which inherits the priority
+ <braunr> easy to fix but worth saying to keep in mind
+ <youpi> uh
+ <youpi> indeed
+
+
## IRC, freenode, #hurd, 2012-12-05
<braunr> tschwinge: i'm currently working on a few easy bugs and i have
diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn
index a4311d3e..182fb6f9 100644
--- a/open_issues/linux_vmsig.mdwn
+++ b/open_issues/linux_vmsig.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
@@ -27,3 +27,18 @@ From a quick glance, this sounds to [[me|tschwinge]] quite a bit like
mechanisms also found in (originating in?) Mach's
[[microkernel/mach/external_pager_mechanism]]. May be worth having a look at
it.
+
+
+# IRC, freenode, #hurd, 2013-03-06
+
+ <braunr> tschwinge: from a quick look, this isn't similar to the external
+ pager mechanism
+ <braunr> it's an additional tool to help userspace application manage
+ internal caches
+ <braunr> it's similar to what is done to reclaim memory from the slab
+ allocator for example
+ <braunr> and it would indeed be a very good thing to have so that e.g. the
+ hurd can build a distributed but completely dynamic dentry-like cache
+ <braunr> i'm actually glad to see someone else thought of using real time
+ signals for this
+ <braunr> i didn't do any research on that subject yet
diff --git a/open_issues/managed_runtime_initiative.mdwn b/open_issues/managed_runtime_initiative.mdwn
new file mode 100644
index 00000000..7a880beb
--- /dev/null
+++ b/open_issues/managed_runtime_initiative.mdwn
@@ -0,0 +1,72 @@
+[[!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-04-02
+
+ <psockali> hi again, maybe someone has some metrics
+ <psockali> is mprotect / munprotect faster in hurd then in linux ?
+ <pinotree> ?
+ <psockali> can i protected a memory page against write access in hurd
+ <psockali> and if so, is it a fast operation ?
+ <youpi> you can, I never measured, but it's probably the same cost as in
+ linux
+ <youpi> I don't see why it would be different, as it boils down to the same
+ x86 trick
+ <psockali> but i suppose it is part of the mach kernel doing the protection
+ and not part of the unix layer ?
+ <youpi> it is
+ <youpi> the unix layer doesn't have mm control
+ <youpi> it has to ask the kernel
+ <braunr> it's slower on mach, as it's less optimized because of historical
+ reasons
+ <braunr> but that's about it
+ <youpi> less optimized, how so?
+ <braunr> well, more entry fragmentation
+ <youpi> in the end you mark the page table and flush the tlb
+ <braunr> yes
+ <braunr> the high level virtual memory layer is a bit slower
+ <youpi> but fragmentation doesn't come into play it you just have one
+ memory object, does it?
+ <braunr> it does, as it's about memory areas, not objects
+ <braunr> the object is merely a backing store
+ <braunr> protection, inheritance, copy on write are all area (vm_map_entry)
+ attributes
+ <braunr> also, some operations affect all the address spaces where a
+ physical page is mapped
+ <braunr> although i think linux does the same thing as mach/bsd now
+ <youpi> but mprotect/munprotect doesn't, does it?
+ <braunr> no
+ <braunr> or perhaps by side effect, in some situations, i'm not sure
+ <braunr> i think it depends if the memory is shared between processes, but
+ i don't remember the details and can't think of a proper example right
+ now
+ <braunr> but anyway, "slower" here is negligible unless address spaces are
+ really huge and filled with lots of map entries
+ <braunr> psockali: why do you ask ?
+ <psockali> can i post a link here ?
+ <braunr> about what ?
+ <psockali> it's regarding azul / managed runtime initiative
+ <psockali> a GC for java
+ <braunr> why not
+ <braunr> although i don't see the point for now :)
+ <psockali> they have a custom MM management module for their GC as linux
+ kernel modul
+ <psockali> and i was wondering if mach would be any faster then linux in
+ that aspect
+ <psockali>
+ http://stackoverflow.com/questions/3358545/whats-actually-in-the-managed-runtime-initiatives-kernel-patches-and-jvm
+ <braunr> psockali: generally speaking, mach is slower than linux because of
+ its age and the fact it didn't receive as much attention and
+ microoptimization as linux did
+ <braunr> psockali: about this article, there is no reason mach would be
+ faster
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index d7804864..03614fae 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -354,6 +354,33 @@ Tom Van Cutsem, 2009.
[[hurd/libpager]].
+### IRC, freenode, #hurd, 2013-03-29
+
+ <braunr> some day i'd like to add a system call that threads can use to
+ terminate themselves, passing their stack as a parameter for deallocation
+ <braunr> then, we should review the timeouts used with libports management
+ <braunr> having servers go away when unneeded is a valuable and visible
+ feature of modularity
+
+
+### IRC, freenode, #hurd, 2013-04-03
+
+ <braunr> youpi: i also run without the libports_stability patch
+ <braunr> and i'd like it to be removed unless you still have a good reason
+ to keep it around
+ <youpi> well, the reason I know is mentioned in the patch
+ <youpi> i.e. the box becomes unresponsive when all these threads wake up at
+ the same time
+ <youpi> maybe we could just introduce some randomness in the sleep time
+ <braunr> youpi: i didn't experience the problem
+ <youpi> well, I did :)
+ <braunr> or if i did, it was very short
+ <youpi> for the libports stability, I'd really say take a random value
+ between timeout/2 and timeout
+ <youpi> and that should just nicely fix the issue
+ <braunr> ok
+
+
## Alternative approaches:
* <http://www.concurrencykit.org/>
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
index e27d3018..1f4c6ab8 100644
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -387,3 +387,43 @@ here.
<youpi> the issue is mach not supporting enough sched levels
<youpi> can be fixed, of course
<youpi> just nobody did yet
+
+GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit
+6fe36b76f7983ec9a2e8a70420e431d54252442e).
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-07
+
+ <braunr> youpi: btw, why did you increase the number of priorites to 50 ?
+ <youpi> for the nice levels
+ <braunr> and probably something more, there are only 40 nice levels
+ <youpi> yes, the current computation leaves some margin
+ <youpi> so I preferred to keep a margin too
+ <braunr> ok
+ <youpi> e.g. for the idle thread, etc.
+ <braunr> or interrupt threads
+ <youpi> yep
+ <braunr> i see the point, thanks
+ <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that
+ a Linuxism?
+ <braunr> good question
+ <braunr> posix is weird when it comes to such old unixisms
+ <braunr> there is a NZERO value, but i don't remember how it's specified
+ <youpi> it's at least 20
+ <tschwinge> (I don't object to the change; just wondered. And if practice,
+ you probably wouldn't really need more than a handful. But if that
+ change (plus some follow-up in glibc (?) improves something while not
+ adding a lot of overhead, then that's entirely fine, of course.)
+ <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0
+ shall be imposed by the system"
+ <braunr> NZERO being 20 by default
+ <youpi> and 20 is the minimum for NZERO too
+ <braunr> hm, not the default, the minimul
+ <braunr> minimum
+ <braunr> yes that's it
+ <braunr> ok so it's actually well specified
+ <tschwinge> Aha, I see (just read it, too). So before that change we
+ simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20,
+ and allowing for step-1 increments. Alright.
+ <youpi> yep
+ <youpi> thus failing in coreutils testsuite
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 8a8ba823..768dca93 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -2989,3 +2989,45 @@ License|/fdl]]."]]"""]]
determine what m_o_ function will be used
<mcsim> now default_read calls m_o_ on its own
<braunr> ok
+
+
+## IRC, freenode, #hurd, 2013-03-06
+
+ <mcsim> braunr: hi, regarding memory policies. Should I create separate
+ policy that will do pageout or VM_ADVICE_SEQUENTIAL is good enough?
+ <mcsim> braunr: at the moment it is exactly like NORMAL
+ <braunr> mcsim: i thought you only did pageins
+ <mcsim> braunr: yes, but I'm doing pageouts now
+ <braunr> oh
+ <braunr> i'd prefer you didn't :/
+ <braunr> if you want to improve paging, i have a suggestion i believe is a
+ lot better
+ <braunr> and we have 3 patches concerning libpager that we need to review,
+ polish, and merge in
+ <mcsim> braunr: That's not hard, and I think I know what to do
+ <braunr> yes i understand that
+ <braunr> but it may change the interface and conflict with the pending
+ changes
+ <mcsim> braunr: What changes?
+ <braunr> the large store patch, neal's libpager rework patch on top of
+ which you made your changes, and your changes
+ <braunr> the idea i have in mind was writeback throttling
+
+[[hurd/translator/ext2fs]], [[hurd/libpager]].
+
+ <braunr> i was planning on doing it myself but if you want to work on it,
+ feel free to
+ <braunr> it would be a much better improvement at this time than clustered
+ pageouts
+ <braunr> (which can then immediately follow
+ <braunr> )
+ <mcsim> braunr: ok
+ <mcsim> braunr: but this looks much more bigger task for me
+ <braunr> we'll talk about the strategy i had in mind tomorrow
+ <braunr> i hope you find it simple enough
+ <braunr> on the other hand, clustered pageouts are very similar to pageins
+ <braunr> and we have enough paging related changes to review that adding
+ another wouldn't be such a problem actually
+ <mcsim> so, add?
+ <braunr> if that's what you want to do, ok
+ <braunr> i'll think about your initial question tomorrow
diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn
index 387ad4fe..5db192e3 100644
--- a/open_issues/pfinet_timers.mdwn
+++ b/open_issues/pfinet_timers.mdwn
@@ -15,3 +15,105 @@ License|/fdl]]."]]"""]]
<braunr> now that there is a pthread_hurd_cond_timedwait_np function
available, we could replace the ulgy timers in pfinet
+
+
+# IRC, freenode, #hurd, 2013-04-02
+
+ <braunr> youpi: also, i think i know why fakeroot is slow on the hurd
+ <braunr> well, pfinet actually
+ <youpi> tcp flow control?
+ <braunr> i think it's because of our timer resolution
+ <youpi> ah
+ <braunr> and i think i spotted a small mistake in the timer emulation code
+ btw
+ <braunr> it's so obvious i even doubt it's actually true :)
+ <braunr> see timer_emul.c:timer_function
+ <braunr> the code checks for timers->expires < jiffies
+ <braunr> shouldn't it be "<="
+ <braunr> ?
+ <youpi> well it'd be equivalent
+ <youpi> if ==, then wait becomes 0 in the else
+ <braunr> see the second scheck
+ <braunr> the one performed right before running the callback
+ <youpi> ah, the while?
+ <braunr> yes
+ <youpi> I'd say <= could do it yes
+ <braunr> ok
+ <braunr> i have hurd packages ready to be tested
+ <youpi> although I'm unsure it'd make a difference
+ <youpi> do you notice some?
+ <braunr> just waiting for my current glibc to finish building
+ <braunr> and i'll test right after
+ <braunr> i think it would actually
+ <youpi> in which case?
+ <braunr> the timer resolution is 10ms
+ <braunr> it's huge
+ <braunr> well, i hope it fixes fakeroot slowness :)
+ <youpi> so timers below that would trigger immediately?
+ <braunr> or equal
+ <braunr> taht's the problem
+ <braunr> for 10ms, timers that have expired must wait for the next tick to
+ fire
+ <youpi> I include "equal" in below
+ <youpi> actually :)
+ <braunr> then yes :)
+ <braunr> soryy i never know when equal is implicit
+ <youpi> because they boil down to expires = jiffies
+ <youpi> in french it's implicit
+ <youpi> but anyway here equal is not really important
+ <braunr> right
+ <braunr> why ?
+ <youpi> it's the fact that 1ms would be rounded up to 10ms, not down to 0ms
+ <braunr> well, doing that seems reasonable
+ <youpi> or rather, rounded down to 0ms, but waited for 10ms because of the
+ <
+ <braunr> we do want timers not to fire before the time event
+ <youpi> I'm however wondering which part of the code would have timer below
+ 10ms
+ <braunr> well, a select with low timeout from a client perhaps ?
+ <youpi> but then we have to round up
+ <youpi> as you say we don't want to fire before some time
+ <braunr> well yes
+ <braunr> that's fine
+ <youpi> all that being said, linux has been having 10ms clock for a long
+ time
+ <braunr> but when the timer fires, i.e. when expires == jiffie, we do want
+ it to fire
+ <youpi> highres timers are only relativeley recent
+ <braunr> not at jiffie + 1
+ <youpi> braunr: ah, right, so we don't wait for 20ms instead of 10ms
+ <braunr> yes
+ <youpi> ok, so it's not a miracle fix, but could bring 2times fix
+ <braunr> well, pfinet eats 40% of my processor when this problem occurs
+ <braunr> which i'm seeing right now
+ <youpi> yes, I've seen that too
+ <braunr> so it may be a visible win
+ <braunr> build finished :) let's see
+ <youpi> Mmm, thinking again
+ <youpi> indeed
+ <youpi> when expires become jiffies
+ <youpi> we mach_msg (0)
+ <youpi> but don't do anything
+ <youpi> and then restart
+ <youpi> so just eaten cpu for nothing
+ <braunr> is there a small package that builds fast and uses fakeroot a lot
+ ?
+ <youpi> something like a package which has a lot of data to install at make
+ install
+ <braunr> or i can rebuild glibc with -nc
+ <youpi> ok, I've checked in linux
+ <pinotree> libarchive's testsuite used to intermittently failing under
+ fakeroot
+ <youpi> it's definitely <= which is meant
+ <braunr> it looks better
+ <braunr> but still not 100% cpu
+ <youpi> at any rate, as long as it doesn't seem to break anything, please
+ push the fix
+ <youpi> it definitely makes sense
+ <youpi> (and I don't see why it could break anything)
+ <braunr> ok
+ <braunr> i'll look into this timer problem a bit more, there may be other
+ code involved
+ <braunr> yes, schedule_timeout could need a review
+ <braunr> actually, fakeroot rm -rf * is a good test
+ <braunr> and it's still damn slow
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn
index bd9abcf9..0d786d2a 100644
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ b/open_issues/translate_fd_or_port_to_file_name.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
@@ -15,14 +16,17 @@ License|/fdl]]."]]"""]]
# IRC, freenode, #hurd, June (?) 2010
- <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port?
+ <pochu> is there a way (POSIX or Hurdish) to get the corresponding file
+ name for a fd or a hurd port?
<marcusb> there is a way
<pochu> marcusb: which one would that be?
<marcusb> I forgot
<marcusb> there is an implementation in libc
<marcusb> realpath has a similar job
<marcusb> but that's not what I mean
- <marcusb> pochu: maybe I am misremembering. But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for
+ <marcusb> pochu: maybe I am misremembering. But it was something where you
+ keep looking up .. and list that directory, looking for the node with the
+ ID of the node you had .. for
<marcusb> maybe it works only for directories
<marcusb> yeah
<marcusb> pochu: check the getcwd() implementation of libc
@@ -30,20 +34,25 @@ License|/fdl]]."]]"""]]
<marcusb> _hurd_canonicalize_directory_name_internal 
* pochu looks
<pochu> marcusb: interesting
- <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file
+ <pochu> though that is for dirs, and doesn't seem to be extensible to
+ files, as you cannot lookup for ".." under a file
<marcusb> right
<pochu> oh you already said that :)
<marcusb> actually, I am not sure that's correct
- <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in
- <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that
+ <marcusb> it's probably correct, but there is no reason why looking .. up
+ on a file couldn't return the directory it's contianed in
+ <pochu> I don't know the interfaces or the Hurd internals very well yet,
+ but it would look strange to me if you could do that
<marcusb> the hurd is strange
- <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-)
+ <pochu> it sounds like if you could `ls getcwd.c/..` to get
+ sysdeps/mach/hurd/ :-)
<marcusb> yep
<pochu> ok. interesting
<marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you?
<pochu> I guess not if `ls foo.zip` listed the contents of foo.zip
<marcusb> there you go
- <marcusb> or the other way round: would you be surprised if "cat somedir" would work?
+ <marcusb> or the other way round: would you be surprised if "cat somedir"
+ would work?
<pochu> I think so. if it did, what would it do?
<marcusb> originally, cat dir would list the directory content!
<marcusb> in the old unix times
@@ -51,10 +60,49 @@ License|/fdl]]."]]"""]]
<marcusb> and some early BSDs
* pochu feels young :-)
<marcusb> he don't worry, I didn't see those times either
- <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface
+ <marcusb> technically, files and directories are implemented in the same
+ way in the hurd, they both are objects implementing the fs.defs interface
<marcusb> which combines file and directory operations
- <marcusb> of course, files and directories implement those functions differently
- <antrik> marcusb: do you know why this behavior (cat on directories) was changed?
+ <marcusb> of course, files and directories implement those functions
+ differently
+ <antrik> marcusb: do you know why this behavior (cat on directories) was
+ changed?
+
+
+## IRC, freenode, #hurd, 2013-03-07
+
+ * pinotree ponders about sending as RFC his patch for /proc/$pid/maps
+ <tschwinge> Including a scheme for providing the names of mapped files?
+ ;-D
+ <braunr> that would be really great indeed
+ <tschwinge> I have not yet researched how Linux does this. Perhaps store
+ the filename used for first opening a file as a string somewhere?
+ <pinotree> tschwinge: eh, indeed that's lacking in my patch
+ <braunr> i'm not sure we should aim at doing it the same way
+ <youpi> I was wondering about having interfaces for naming tasks, threads,
+ objects
+ <youpi> that'd be useful for debugging in general
+ <braunr> yes
+ <braunr> i don't think we need to take namespaces into account
+ <braunr> a simple name or path should be quite enough
+ <tschwinge> Agreed. "Just something!"
+ <tschwinge> So, a Java toString() method for ports.
+ <tschwinge> ;-)
+ <braunr> yes
+ <tschwinge> Oh, and could this also work recursively? The ext2fs instance
+ on /home asks its parent fs about its own path -- can it do that? (And
+ then cache that, most likely?) Would one get rooted filesnames that way?
+ <braunr> i really don't think we should link it to the VFS
+ <braunr> it should merely be a name for debugging
+ <youpi> yep, same for me
+ <youpi> I'd say it's the linker's task of just setting a sane name
+ <braunr> first, keeping it isolated prevents increasing complexity
+ <braunr> next, it doesn't reduce performance
+ <tschwinge> youpi: Linker?
+ <tschwinge> braunr: Ack.
+ <braunr> yes, ld is the one creating the mappings
+ <youpi> tschwinge: the one that loads libraries
+ <tschwinge> Ah, for /proc/*/maps, right. I've been thinking more globally.
# IRC, freenode, #hurd, 2011-07-13
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index ec762b59..f4739776 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -15,3 +15,10 @@ License|/fdl]]."]]"""]]
<youpi> btw, about fakeroot-hurd
<youpi> the remaining issue I see is with argv[0] (yes, again...)
+
+
+## IRC, freenode, #hurd, 2013-04-03
+
+ <youpi> btw, I believe our fakeroot-hurd is close to working actually
+ <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
+ but apparently not fixed in that case, for some reason
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
index 67d64ae0..dcef310d 100644
--- a/open_issues/virtualization/remap_root_translator.mdwn
+++ b/open_issues/virtualization/remap_root_translator.mdwn
@@ -139,3 +139,8 @@ License|/fdl]]."]]"""]]
<youpi> let me just comment out that :)
<youpi> way better :)
<youpi> yep, just works fine
+
+
+# IRC, freenode, #hurd, 2013-03-16
+
+ <braunr> youpi: is the /bin/remap --help output correct ?