diff options
Diffstat (limited to 'open_issues')
| -rw-r--r-- | open_issues/anatomy_of_a_hurd_system.mdwn | 32 | ||||
| -rw-r--r-- | open_issues/clock_gettime.mdwn | 9 | ||||
| -rw-r--r-- | open_issues/glibc/debian/experimental.mdwn | 115 | ||||
| -rw-r--r-- | open_issues/libpthread.mdwn | 13 | ||||
| -rw-r--r-- | open_issues/linux_vmsig.mdwn | 17 | ||||
| -rw-r--r-- | open_issues/managed_runtime_initiative.mdwn | 72 | ||||
| -rw-r--r-- | open_issues/multithreading.mdwn | 27 | ||||
| -rw-r--r-- | open_issues/nice_vs_mach_thread_priorities.mdwn | 40 | ||||
| -rw-r--r-- | open_issues/performance/io_system/read-ahead.mdwn | 42 | ||||
| -rw-r--r-- | open_issues/pfinet_timers.mdwn | 102 | ||||
| -rw-r--r-- | open_issues/time.mdwn | 75 | ||||
| -rw-r--r-- | open_issues/translate_fd_or_port_to_file_name.mdwn | 70 | ||||
| -rw-r--r-- | open_issues/virtualization/fakeroot.mdwn | 7 | ||||
| -rw-r--r-- | open_issues/virtualization/remap_root_translator.mdwn | 5 |
14 files changed, 612 insertions, 14 deletions
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn index 3e585876..8119cdd5 100644 --- a/open_issues/anatomy_of_a_hurd_system.mdwn +++ b/open_issues/anatomy_of_a_hurd_system.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 @@ -347,3 +348,32 @@ Need more stuff like that. <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 83ad81e8..b2fbf3e0 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -184,3 +184,12 @@ In context of [[select]]. <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 + + +# 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 :) 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 f0c0db58..acc03efd 100644 --- a/open_issues/libpthread.mdwn +++ b/open_issues/libpthread.mdwn @@ -1287,6 +1287,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task. <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 be582e8a..4034e940 100644 --- a/open_issues/performance/io_system/read-ahead.mdwn +++ b/open_issues/performance/io_system/read-ahead.mdwn @@ -2983,3 +2983,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/time.mdwn b/open_issues/time.mdwn index ab239aef..cc3951c3 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -1,4 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 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 @@ -67,3 +68,75 @@ While testing some [[performance/IPC_virtual_copy]] performance issues: <tschwinge> And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k running, a parallel sleep 10 takes about 20 s (on strauss). + + +# IRC, OFTC, #debian-hurd, 2013-03-30 + + <clopez> /usr/bin/time seems broken on hurd. It reports weird things. Ex: + <clopez> # /usr/bin/time sleep 1 + <clopez> 0.00user 0.00system 4:37:46elapsed 0%CPU (0avgtext+0avgdata + 0maxresident)k + <clopez> 0inputs+0outputs (0major+0minor)pagefaults 0swaps + <pinotree> o_O + <pinotree> indeed, let's see what that time does + <pinotree> seems like only the elapsed time, %E + <clopez> not only the time, but also the other variables (pagefaults, cpu + used, etc) are wrong. For example compare the output of + <clopez> /usr/bin/time openssl speed ecdhp521 + <clopez> on linux and hurd + <pinotree> most probably they are not implemented yet + <pinotree> they are all 0 + <clopez> yes + <clopez> should i report a bug to pkg time? + <pinotree> not sure + <pinotree> at least, there's this difference between eg amd64 and hurd-i386 + in configure's output: + <pinotree> -checking for wait3 that fills in rusage... yes + <pinotree> +checking for wait3 that fills in rusage... no + <clopez> found this: + https://www.gnu.org/software/hurd/open_issues/time.html + <pinotree> seems related, yes + <pinotree> clopez: apparently all the ways to get the HZ define, either + directly or with CLOCKS_PER_SEC or CLK_TCK, so it gets defined as HZ + <pinotree> ... as 60, i mean (instead of 1000000) + <pinotree> $ ./time sleep 1 + <pinotree> 0.00user 0.00system 0:01.01elapsed 0PU (0avgtext+0avgdata + 0maxresident)k + <pinotree> :) + <clopez> what it was? + <pinotree> i added the check for time.h, and included in the no-wait3 case + in resuse.c + <pinotree> (omg, the last release of gnu time was in 1997) + <clopez> lol + <pinotree> hm not yet fixed + <pinotree> oh minor typo + <pinotree> clopez: http://paste.debian.net/246004/ + <pinotree> i will update the wiki page (on the hurd site) and send the + patch tomorrow + <clopez> nice + <pinotree> yw, thanks again + <clopez> i dropped the patch on debian/patches of pkg time.. rebuilt it + both on linux and hurd + <clopez> and works as expected in both cases + <clopez> i think you should forward the patch to the mantainer of pkg time + <pinotree> is there anyone maintaining gnu time? + <clopez> http://packages.qa.debian.org/t/time.html + <clopez> Maintainers for time are Bob Proulx <bob@proulx.com>. + <pinotree> that's the debian maintainer, yes, which is what i implied + earlier with "send the patch" + <clopez> i guess that filling a bug against time with this patch attached + should be enough + <pinotree> yeah + <clopez> wow... not only you fixed the elapsed time but also the other + variables :) + <clopez> /usr/bin/time openssl speed ecdhp521 + <clopez> now it reports cpu used and pagefaults :) + <pinotree> does it? + <clopez> 10.00user 0.01system 0:10.11elapsed 99%CPU (0avgtext+0avgdata + 0maxresident)k + <clopez> 0inputs+0outputs (67major+656minor)pagefaults 0swaps + + +# IRC, OFTC, #debian-hurd, 2013-03-31 + + <pinotree> clopez: #704283 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 ? |