diff options
25 files changed, 918 insertions, 26 deletions
diff --git a/community/gsoc/project_ideas/smp.mdwn b/community/gsoc/project_ideas/smp.mdwn index d9788e56..c6da2c41 100644 --- a/community/gsoc/project_ideas/smp.mdwn +++ b/community/gsoc/project_ideas/smp.mdwn @@ -10,6 +10,8 @@ License|/fdl]]."]]"""]] [[!meta title="SMP"]] +See also the [[FAQ entry|faq/smp]]. + # IRC, freenode, #hurd, 2012-09-30 @@ -19,3 +21,12 @@ License|/fdl]]."]]"""]] ## IRC, freenode, #hurd, 2013-01-02 <braunr> i'd like to mentor someone for adding smp to gnumach + + +## IRC, freenode, #hurd, 2013-03-14 + + <braunr> but i'm afraid we'll have to fight obscur smp-safety issues + <braunr> for one, drivers are much probably not smp safe and would require + a big kernel lock + <braunr> userspace (such as signal delivery in libc) might be affected too + <braunr> smp isn't that easy diff --git a/faq/smp.mdwn b/faq/smp.mdwn index e95edcd2..04396401 100644 --- a/faq/smp.mdwn +++ b/faq/smp.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 @@ -26,3 +27,5 @@ That is why for now GNU/Hurd will only use one logical processor (i.e. one core Once this issue is solved, there are follow-up issues about [[open_issues/multiprocessing]] and [[open_issues/multithreading]]. + +[[GSoC project idea|gsoc/project_ideas/smp]]. @@ -94,6 +94,7 @@ in the *unstable* branch of the Debian archive. * [[libihash]] * [[libthreads]] * [[libpthread]] + * [[libps]] * [[IO_Path]] * [[Porting]] * [[Debugging]] diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn index c506861a..de72ae4c 100644 --- a/hurd/debugging/rpctrace.mdwn +++ b/hurd/debugging/rpctrace.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012 Free Software -Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 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 @@ -175,6 +175,10 @@ See `rpctrace --help` about how to use it. /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287: trace_and_forward: Assertion `reply_type == 18' failed. + * IRC, OFTC, #debian-hurd, 2013-03-14 + + <youpi> uhu, there's a TODO just above that assertion :) + # See Also diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn index d6b8e8b6..be20fa58 100644 --- a/hurd/libihash.mdwn +++ b/hurd/libihash.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2009, 2010, 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 @@ -19,19 +19,26 @@ License|/fdl]]."]]"""]] * hurd-l4 libhurd-ihash + +# Open Issues + * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]] - IRC, unknown channel, unknown date + IRC, freenode, #hurd, 2008/2009 <neal> so, we need a new ihash implementation <neal> marcusb: When 80% full, the collision rate is very high. <neal> marcusb: I tested using 512mb / 4096 entries - <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster. + <neal> marcusb: Changing the load factor to 30% resulted in my program + running more than an order of magnitude faster. <marcusb> yeah, it shouldn't get so full <marcusb> don't we do an exponential back-off in the array size? <marcusb> of course it's clear we can do much better <marcusb> the ihash algo is very simple - <marcusb> I'm not even sure it makes much sense to have a generic library + <marcusb> I'm not even sure it makes much sense to have a generic + library + + * [[community/gsoc/project_ideas/object_lookups]] # Alternatives? diff --git a/hurd/libps.mdwn b/hurd/libps.mdwn new file mode 100644 index 00000000..05ab3ad1 --- /dev/null +++ b/hurd/libps.mdwn @@ -0,0 +1,27 @@ +[[!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]]."]]"""]] + +`libps` provides an API for accessing process information. An alternative is a +[[Linux-compatible `/proc` filesystem|translator/procfs]]. + + +# IRC, OFTC, #debian-hurd, 2013-03-09 + +[[!tag open_issue_documentation]] + + <Steap> what's the difference between PSTAT_STATE_P_STOP and + PSTAT_STATE_T_HALT in libps/ps.h ? + <youpi> Steap: from reading the gnumach source, it seems halted threads are + thread which have finished they work but not finished terminating yet + <youpi> while STOP is the standard preempted state + <youpi> i.e. not sleeping, but have handed cpu to another thread + <Steap> youpi: thanks. Is this "halted" state similar to anything in Linux + ? + <youpi> TASK_DEAD, probably diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 65361ff4..b276ff0c 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -89,6 +89,37 @@ small backend stores, like floppy devices. <youpi> which can be quite probable +##### IRC, freenode, #hurd, 2013-03-19 + + <braunr> youpi: i'm back on polishing the large store patch + <braunr> did you remember seeing something else than the bzero/memset + out-of-scope changes ? + <braunr> (i mean, readily noticeable) + <youpi> I don't remember + <braunr> ok + <braunr> the original code already assumes mmap succeeds + <braunr> is it ok to consider the patch can do the same ? + <youpi> I'd say so + <braunr> ok + <braunr> youpi: actually, it looks like a good part of the patch isn't + related to large stores + <braunr> for example, in ext2fs/inode.c, there are calls to + dino_ref/dino_deref + <youpi> hum + <braunr> i'm not sure at all these have anything to do with handling large + stores + <youpi> but dino_ref is introduced by this patch, isn't it? + <braunr> it replaces dino + <youpi> yes, it replaces it because the dino() approach can't work beyond + 2GiB + <braunr> i see + <braunr> youpi: i'd like to replace the recursive call to + disk_cache_block_ref with a goto, is that fine with you ? + <youpi> looks ok to me + <youpi> better than relying on tail recursion + <braunr> that's the idea :) + + #### [[libpager]] API change ##### IRC, freenode, #hurd, 2013-03-04 diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn index 50b5dfc2..3232e0cc 100644 --- a/hurd/translator/pfinet/implementation.mdwn +++ b/hurd/translator/pfinet/implementation.mdwn @@ -1,13 +1,58 @@ -[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2000, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The `pfinet` server is a hacked Linux internet implementation with a glue layer translating between the Hurd [[RPC]]s and the middle layer of the Linux implementation. + + +# Bugs + +## Those Listed on [[Open_Issues]] + +## [[IPv6]] + +## IRC, freenode, #hurd, 2013-04-03 + + <braunr> youpi: there are indeed historical bugs with small packets and + tcp_nodelay in linux 2.0/2.2 tcp/ip + <youpi> oh + <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html + + +# Reimplementation, [[!GNU_Savannah_task 5469]] + +## IRC, freenode, #hurd, 2013-04-03 + +[[!tag open_issue_hurd]] + + <youpi> I was thinking about just using liblwip this afternoon, btw + <braunr> what is it ? + <braunr> hm, why not + <braunr> i would still prefer using code from netbsd + <braunr> especially now with the rump kernel project making it even easier + <youpi> well, whatever is easy to maintain up to date actually + <braunr> netbsd's focus on general portability normally makes it easy to + maintain + <braunr> the author of the rump project was able to make netbsd code run in + browsers :) + <braunr> and he actually showed clients using the networking stack on + windows, remotely (not in the same process) + <braunr> so that's very close to what we want + <youpi> indeed + <youpi> though liblwip is exactly the same portability focus :) + <braunr> apparently, for embedded systems + <youpi> but bsd's code is probably better + <youpi> yes + <braunr> i think so, more general purpose, larger user base + <youpi> I used it for the stubdomains in Xen + <youpi> (it = lwip) + <braunr> ok diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index 42ee3c55..824cc733 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -158,3 +158,17 @@ Amongst other things, support for [[IOCTL]]s is missing. <youpi> I don't remember its url <braunr> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git <braunr> might be even older + + +## IRC, freenode, #hurd, 2013-04-01 + + <congzhan`> hi, the ipv6 route works or not? + <congzhan`> I can use ipv6 to connect vms, but the vm can't access other + host except the router + <congzhan`> the ipv6 route -G seems not work for me, anyone make it work? + <youpi> I'm using SLAAC + <congzhan`> youpi: you mean static config not work? + <youpi> I mean automatic config does work + <youpi> I don't use static config myself + <congzhang> youpi: My ipv6 works now, just because not fully enable ipv6 + forwarding and firewall, thank you:) diff --git a/hurd/translator/tarfs.mdwn b/hurd/translator/tarfs.mdwn index e25e3255..2e37d9cf 100644 --- a/hurd/translator/tarfs.mdwn +++ b/hurd/translator/tarfs.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 @@ -20,6 +20,21 @@ Works fine on most cases, occasional corruptions when writing using bzip2/gzip stores. +## IRC, freenode, #hurd, 2013-03-16 + +[[!tag open_issue_hurd]] + + <pinotree> hm is tarfs working? its simple test suite fails here + (translator dies with gz and bz2 compression) + <braunr> no idea + <braunr> have you tried without compression ? + <pinotree> that succeeds + <braunr> it might rely on storeio for compression + <pinotree> no, it does gz/bz2 on its own + <pinotree> but it uses libstore for i/o of the file + <braunr> ok + + # Source incubator, tarfs/master diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index b3e1758c..dcabb56e 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -615,3 +615,139 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. way it is in mach and netbsd <braunr> but the arch-specific interfaces aren't well defined yet because there is only one (and incomplete) arch + + +### IRC, freenode, #hurd, 2013-03-08 + + <antrik> BTW, what is your current direction? did you follow through with + abandonning Mach resemblance?... + <braunr> no + <braunr> it's very similar to mach in many ways + <braunr> unless mach is defined by its ipc in which case it's not mach at + all + <braunr> the ipc interface will be similar to the qnx one + <antrik> well, Mach is pretty much defined by it's IPC and VM interface... + <braunr> the vm interface remains + <antrik> its + <braunr> although vm maps will be first class objects + <braunr> so that it will be possible to move parts of the vm server outside + the kernel some day if it feels like a good thing to do + <braunr> i.e. vm maps won't be inferred from tasks + <braunr> not implicitely + <braunr> the kernel will be restricted to scheduling, memory management, + and ipc, much as mach is (notwithstanding drivers) + <antrik> hm... going with QNX IPC still seems risky to me... it's designed + for simple embedded environments, not for general-purpose operating + systems in my understanding + <braunr> no, the qnx ipc interface is very generic + <braunr> they can already call remote services + <braunr> the system can scale well on multiprocessor machines + <braunr> that's not risky at all, on the contrary + <antrik> yeah, I'm sure it's generic... but I don't think anybody tried to + build a Hurd-like system on top of it; so it's not at all clear whether + it will work out at all... + <auronandace> clueless question: does x15 have any inspiration from + helenos? + <braunr> absolutely none + <braunr> i'd say x15 is almost an opposite to helenos + <braunr> it's meant as a foundation for unix systems, like mach + <braunr> some unix interfaces considered insane by helenos people (such as + fork and signals) will be implemented (although not completely in the + kernel) + <braunr> ipc will be mostly synchronous + <braunr> they're very different + <braunr> well, helenos is very different + <auronandace> cool + <braunr> x15 and actually propel (the current name i have for the final + system), are meant to create a hurd clone + <auronandace> another clueless question: any similarities of x15 to minix? + <braunr> and since we're few, implementing posix efficiently is a priority + goal for me + <braunr> again, absolutely none + <braunr> for the same reasons + <braunr> minix targets resilience in embedded environments + <braunr> propel is a hurd clone + <braunr> propel aims at being a very scalable and performant hurd clone + <braunr> that's all + <auronandace> neato + <braunr> unfortunately, i couldn't find a name retaining all the cool + properties of the hurd + <braunr> feel free to suggest ideas :) + <auronandace> propel? as in to launch forward? + <braunr> push forward, yes + <auronandace> that's very likely a better name than anything i could + conjure up + <braunr> x15 is named after mach (the first aircraft to break mach 4, + reaching a bit less than mach 7) + <braunr> servers will be engines, and together to push the system forward + ..... :) + <auronandace> nice + <auronandace> thrust might be a bit too generic i guess + <braunr> oh i'm looking for something like "hurd" + <braunr> doubly recursive acronym, related to gnu + <braunr> and short, so it can be used as a c namespace + <braunr> antrik: i've thought about it a lot, and i'm convinced this kind + of interface is fine for a hurd like system + <braunr> the various discussions i found about the hurd requirements + (remember roland talking about notifications) all went in this direction + <braunr> note however the interface isn't completely synchronous + <braunr> and that's very important + <antrik> well, I'm certainly curious. but if you are serious about this, + you'd better start building a prototype as soon as possible, rather than + perfecting SMP ;-) + <braunr> i'm not perfecting smp + <braunr> but i consider it very important to have migrations and preemption + actually working before starting the prototype + <braunr> so that tricky mistakes about concurrency can be catched early + <antrik> my current hunch is that you are trying to do too much at the same + time... improving both the implementation details and redoing the system + design + <braunr> so, for example, there is (or will be soon, actually) thread + migratio, but the scheduler doesn't take processor topology into account + <braunr> that's why i'm starting from scratch + <braunr> i don't delve too deep into the details + <braunr> just the ones i consider very important + <antrik> what do you mean by thread migration here? didn't you say you + don't even have IPC?... + <braunr> i mean migration between cpus + <antrik> OK + <braunr> the other is too confusing + <braunr> and far too unused and unknown to be used + <braunr> and i won't actually implement it the way it was done in mach + <braunr> again, it will be similar to qnx + <antrik> oh? now that's news for me :-) + <antrik> you seemed pretty hooked on thread migration when we talked about + these things last time... + <braunr> i still am + <braunr> i'm just saying it won't be implemented the same way + <braunr> instead of upcalls from the kernel into userspace, i'll "simply" + make server threads inherit from the caller's scheduling context + <braunr> the ideas i had about stack management are impossible to apply in + practice + <braunr> which make the benefit i imagined unrealistic + <braunr> and the whole idea was very confusing when compared and integrated + into a unix like view + <braunr> so stack usage will be increased + <braunr> that's ok + <antrik> but thread migration is more or less equivalent with first-class + RPCs AIUI. does that work with the QNX IPC model?... + <braunr> the very important property that threads don't block and wake a + server when sending, and the server again blocks and wake the client on + reply, is preserved + <antrik> (in fact I find the term "first-class RPC" much clearer...) + <braunr> i dont + <braunr> there are two benefits in practice: since the scheduling context + is inherited, the client is charged for the cpu time consumed + <braunr> and since there are no wakeups and blockings, but a direct hand + off in the scheduler, the cost of crossing task space is closer to the + system call + <antrik> which can be problematic too... but still it's the solution chosen + by EROS for example AIUI + <antrik> (inheriting scheduling contexts I mean) + <braunr> by practically all modern microkernel based systems actually, as + noted by shapiro + <antrik> braunr: well, both benefits can be achieved by other means as + well... scheduler activations like in Viengoos should handle the hand-off + part AIUI, and scheduling contexts can be inherited explicitly too, like + in EROS (and in a way in Viengoos) + <braunr> i don't understand viengoos well enough to do it that way 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 ? |