diff options
-rw-r--r--open_issues/libnetfs_vs_libdiskfs.mdwn (renamed from open_issues/libnetfs_argument_parsing.mdwn)58
84 files changed, 11517 insertions, 272 deletions
diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn
index d0185c60..b7de141b 100644
--- a/community/gsoc/2013/hacklu.mdwn
+++ b/community/gsoc/2013/hacklu.mdwn
@@ -615,3 +615,1485 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
found that.
<tschwinge> hacklu: That's how I found it, yes.
<hacklu> tschwinge: :)
+# IRC, freenode, #hurd, 2013-07-14
+ <hacklu> hi. what is a process's msgport?
+ <hacklu> And where can I find the msg_sig_post_untraced_request()?
+ <hacklu> (msg_sig_post* in [hurd]/hurd/msg_defs)
+ <hacklu> this is my debugger demo code
+ use make test to run the demo. I
+ put a breakpoint before the second printf in hello_world(inferior
+ program). but I can't resume execution from that.
+ <hacklu> could somebody give me some suggestions? thanks so much.
+ <teythoon> hacklu: % make test
+ <teythoon> make: *** No rule to make target `exc_request_S.c', needed by
+ `all'. Stop.
+ <hacklu_> teythoon: updated, forget to git add that file .
+ <teythoon> hacklu_: cool, seems to work now
+ <teythoon> will look into this tomorrow :)
+ <hacklu_> exit
+ <hacklu_> teythoon: not work. the code can,t resume from a breakpoint
+# IRC, freenode, #hurd, 2013-07-15
+ <hacklu> hi, this is my weekly
+ report.
+ <hacklu> sadly to unsolve the question of resume from breakpoint.
+ <teythoon> hacklu: have you tried to figure out what gdb does to resume a
+ process?
+ <hacklu> teythoon: hi. em, I have tried, but haven't find the magic in gdb
+ yet.
+ <teythoon> have you tried rpctrace'ing gdb?
+ <hacklu> no, rpctrace has too many noise. I turned on the debug in gdb.
+ <hacklu> I don't want rpctrace start gdb as its child task. if it can
+ attach at some point instead of at start
+ <teythoon> hacklu: you don't need to use gdb interactively, you could pipe
+ some commands to it
+ <hacklu> teythoon: that sounds a possible way. I am try it, thank you
+ <hacklu> youpi: gdb can't work correctlly with rpctrace even in batch
+ mode.
+ <hacklu> get something like this "rpctrace: get an unknown send right from
+ process 2151"
+ <youpi> hacklu: well, ideally, fix rpctrace );
+ <youpi> ;)
+ <youpi> hacklu: but you can also as on the list, perhaps somebody knows
+ what you need
+ <hacklu> ok.
+ <hacklu> or I should debug gdb more deeply.
+ <youpi> do both
+ <youpi> so either of them may win first
+ <hacklu> braunr: I have found that, if there is no exception appears, the
+ signal thread will not be createed. Then there is only one thread in the
+ task.
+# IRC, freenode, #hurd, 2013-07-17
+ <hacklu__> braunr: ping
+ <braunr> hacklu__: yes ?
+ <hacklu__> I have reply your email
+ <braunr> i don't understand
+ <braunr> "I used this (&_info)->suspend_count to get the sc value."
+ <braunr> before the thread_info call ?
+ <hacklu__> no, after the call
+ <braunr> but you have a null pointer
+ <braunr> the info should be returned in info, not _info
+ <hacklu__> strange thing is the info is a null pointer. but _info not
+ <braunr> _info isn't a pointer, that's why
+ <braunr> the kernel will use it if the data fits, which is usually the case
+ <hacklu__> in the begin , the info=&_info.
+ <braunr> and it will dynamically allocate memory if it doesn't
+ <braunr> yes
+ <braunr> info should still have that value after the call
+ <hacklu__> but the call had change it. this is what I can;t understand.
+ <braunr> are you completely sure err is 0 on return ?
+ <hacklu__> since the parameter is a pointer to pointer, the thread_info can
+ change it , but I don't think it is a good ideal to set it to null
+ pointer without any err .
+ <hacklu__> yes. i am sure
+ <braunr> info_len is wrong
+ <braunr> it should be the number of integers in _info
+ <braunr> i.e. sizeof(_info) / sizeof(unsigned int)
+ <braunr> i don't think that's the problem though
+ <braunr> yes, THREAD_BASIC_INFO_COUNT is already exactly that
+ <braunr> hm not exactly
+ <braunr> yes, exactly in fact
+ <hacklu__> I try to set it by hand, not use the macro.
+ <braunr> the macro is already defined as #define THREAD_BASIC_INFO_COUNT
+ (sizeof(thread_basic_info_data_t) / sizeof(natural_t))
+ <hacklu__> the info_len is 13. I checked.
+ <braunr> so, i said something wrong
+ <braunr> the call doesn't reallocate thread_info
+ <braunr> it uses the provided storage, nothing else
+ <braunr> yes, your call is wrong
+ <braunr> use thread_info (thread->port, THREAD_BASIC_INFO, (int *) info,
+ &info_len);
+ <hacklu__> em. thread_info (thread->port, THREAD_BASIC_INFO, (int *) &info,
+ &info_len);
+ <braunr> &info would make the kernel erase the memory where info (the
+ pointer) was stored
+ <braunr> info, not &info
+ <braunr> or &_info directly
+ <braunr> i don't see the need for an intermediate pointer here
+ <braunr> ideally, avoid the cast
+ <hacklu__> but in gnu-nat.c line 3338, it use &info.
+ <braunr> use a union with both thread_info_data_t and
+ thread_basic_info_data_t
+ <braunr> well, try it my way
+ <braunr> i think they're wrong
+ <hacklu__> ok, you are right, use info it is ok. the value is the same as
+ &_info after the call.
+ <hacklu__> but the suspend_count is zero again.
+ <braunr> check the rest of the result to see if it's consistent
+ <hacklu__> I think this line need a patch.
+ <hacklu__> what you mean the rest of the result?
+ <braunr> the thread info
+ <braunr> run_state, sleep_time, creation_time
+ <braunr> see if they make sense
+ <hacklu__> ok, I try to dump it
+ <braunr> bbl
+ <hacklu__> braunr: thread [118] suspend_count=0
+ <hacklu__> run_state=3, flags=1, sleep_time=0,
+ creation_time.second=1374079641
+ <hacklu__> something like this, seems no problems.
+# IRC, freenode, #hurd, 2013-07-18
+ <hacklu__> how to get the thread state from TH_STATE_WAITING to
+ <braunr> hacklu__:
+ <braunr> hacklu__: ah waiting
+ <braunr> hacklu__: this means the thread is waiting for an event
+ <braunr> so probably waiting for a message
+ <braunr> or an internal kernel event
+ <hacklu__> braunr: so I need to send it a message. I think I maybe forget
+ to send some reply message.
+ <braunr> hacklu__: i'm really not sure about those low level details
+ <braunr> confirm before doing anything
+ <hacklu__> the gdb has called msg_sig_post_untraced_request(), I don't get
+ clear about this function, I just call it as the same, maybe I am wrong .
+ <hacklu__> how will if I send a CONT to the stopped process? maybe I should
+ try this.
+ <hacklu__> when the inferior is in waiting
+ status(TH_STATE_WAITING,suspend_count=0), I use kill to send a CONT. then
+ the become(TH_STATE_STOP,suspend_count=1). when I think I am near the
+ success,I call thread_resume(),inferior turn out to be (TH_STATE_WAITING,
+ suspend_count=0).
+ <braunr> so yes, probably waiting for a message
+ <hacklu__> braunr: after send a CONT to the inferior, then send a -9 to the
+ debugger, the inferior continue!!!
+ <braunr> probably because it was notified there wasn't any sender any more
+ <hacklu__> that's funny, I will look deep into thread_resume and kill
+ <braunr> (gdb being the sender here)
+ <hacklu__> in hurd, when gdb attach a inferior, send signal to the
+ inferior, who will get the signal first? the gdb or the inferior?
+ <hacklu__> quite differnet with linux. seems the inferior get first
+ <braunr> do you mean gdb catches its own signal through ptrace on linux ?
+ <hacklu__> kkk
+ <braunr> ?
+# IRC, freenode, #hurd, 2013-07-20
+ <hacklu> braunr: yeah, on Linux the gdb catch the signal from inferior
+ before the signal handler. And that day my network was broken, I can't
+ say goodbye to you. sorry for that.
+# IRC, freenode, #hurd, 2013-07-22
+ <hacklu> hi all, this is my weekly
+ report.
+ <teythoon> good to hear that you got the resume issue figured out
+ <hacklu> teythoon: thanks :)
+ <teythoon> hacklu: so your next step is to port gdbserver to hurd?
+ <hacklu> yep, I am already begin to.
+ <hacklu> before the mid-evaluate, I must submit something. I am far behind
+ my personal expections
+ <tschwinge> hacklu: You've made great progress! Sorry, for not being able
+ to help you very much: currently very busy with work. :-|
+ <tschwinge> hacklu: Working on gdbserver now is fine. I understand you
+ have been working on HDebugger to get an understanding of how everyting
+ works, outside of the huge GDB codebase. It's of course fine to continue
+ working on HDebugger to test things, etc., and that also counts very much
+ for the mid-term evaluation, so nothing to worry about. :-)
+ <hacklu> but I have far away behind my application on GSOC. I haven't
+ submit any patches. is it ok?
+ <tschwinge> hacklu: Don't worry. Before doing the actual work, things
+ always look much simpler than they will be. So I was expecting/planning
+ for that.
+ <tschwinge> The Hurd system is complex, with non-trivial and sometimes
+ asynchronous communication between the different components, and so it
+ takes some time to get an understanding of all that.
+ <hacklu> yes, I haven't get all clear about the signal post. that's too
+ mazy.
+ <tschwinge> hacklu: It surely is, yes.
+ <hacklu> tschwinge: may you help me to understand the msg_sig_post(). I
+ don't want to understand all details now, but I want to get the _right_
+ understanding of the gerneral.
+ <hacklu> as I have mentioned on my weekly report, gdb is listening on the
+ inferior's exception port, then gdb post a signal to that port. That
+ says: gdb post a message to herself, and handle it. is this right?
+ <hacklu> tschwinge: [gdb]/gdb/gnu-nat.c (line 1371), and
+ [glibc]/hurd/hurdsig.c(line 1390)
+ <tschwinge> hacklu: My current understanding is that this is a "real"
+ signal that is sent to the debugged process' signal thread (msgport), and
+ when that process is resumed, it will process that signal.
+ <tschwinge> hacklu: This is different from the Mach kernel sending an
+ exception signal to a thread's exception port, which GDB is listening to.
+ <tschwinge> Or am I confused?
+ <hacklu> is the msgport equal the exception port?
+ <hacklu> in my experience, when the thread haven't cause a exception, the
+ signal thread will not be created. after the exception occured, the
+ signal thread is come out. so somebody create it, who dose? the mach
+ kernel?
+ <tschwinge> hacklu: My understanding is that the signal thread would always
+ be present, because it is set up early in a process' startup.
+ <hacklu> but when I call task_threads() before the exception appears, only
+ on thread returned.
+ <tschwinge> "Interesting" -- another thing to look into.
+ <tschwinge> hacklu: Well, you must be right: GDB must also be listening to
+ the debugged process' msgport, because otherwise it wouldn't be able to
+ catch any signals the process receives. Gah, this is all too complex.
+ <hacklu> tschwinge: that's maybe not. gdb listening on the task's exception
+ port, and the signal maybe handle by the signal thread if it could
+ handle. otherwise the signal thread pass the exception to the task's
+ exception port where gdb catched.
+ <tschwinge> hacklu: Ah, I think I now get it. But let me first verify...
+ ;-)
+ <hacklu> something strange. I have write a program to check whether create
+ signal threads at begining, the all created!
+ <hacklu> tschwinge: this is my test code and
+ result.
+ cat test.c
+ #define _GNU_SOURCE 1
+ #include <stdlib.h>
+ #include <stdio.h>
+ #include <errno.h>
+ #include <mach.h>
+ #include <mach_error.h>
+ int main(int argc,char** argv)
+ {
+ mach_port_t task_port;
+ thread_array_t threads[5];
+ mach_msg_type_number_t num_threads[5];
+ error_t err;
+ task_port = mach_task_self();
+ int i;
+ int j;
+ for(i=0;i<5;i++)
+ if(task_port){
+ err = task_threads(task_port,&threads[i],&num_threads[i]);
+ if(err)
+ printf("err\n");
+ }
+ for(i=0;i<5;i++){
+ printf("===============\n");
+ printf("has %d threads now\n",num_threads[i]);
+ for(j=0;j<num_threads[i];j++)
+ printf("thread[%d]=%d\n",j,threads[i][j]);
+ }
+ return 0;
+ }
+ and the output
+ ./a.out
+ ===============
+ has 2 threads now
+ thread[0]=87
+ thread[1]=97
+ ===============
+ has 2 threads now
+ thread[0]=87
+ thread[1]=97
+ ===============
+ has 2 threads now
+ thread[0]=87
+ thread[1]=97
+ ===============
+ has 2 threads now
+ thread[0]=87
+ thread[1]=97
+ ===============
+ has 2 threads now
+ thread[0]=87
+ thread[1]=97
+ <hacklu> tschwinge: the result is different with HDebugger case.
+ <tschwinge> hacklu: It is my understanding that the two sig_post_untraced
+ RPC calls in inf_signal indeed are invoked on the real msgport (signal
+ thread) if the debugged process.
+ <tschwinge> That port is retrieved via the
+ proc_getmsgport on the proc server, and that will return (unless
+ overridden by proc_setmsgport, but that isn't done in GDB) the msgport as
+ set by [glibc]/hurd/hurdinit.c:_hurd_new_proc_init or _hurd_setproc.
+ <tschwinge> inf_signal is called from gnu_resume, which is via
+ [target_ops]->to_resume is called from target.c:target_resume, which is
+ called several places, for example infrun.c:resume which is used to a)
+ just resume the debugged process, or b) resume it and have it handle a
+ Unix signal (such as SIGALRM, or so), when using the GDB command »signal
+ SIGALRM«, for example.
+ <tschwinge> So such a signal would then not be intercepted by GDB itself.
+ <tschwinge> By the way, this is all just from reading the code -- I hope I
+ got it all right.
+ <tschwinge> Another thing: In Mach 3 Kernel Principles, the standard
+ sequence described on pages 22, 23 is thread_suspend, thread_abort,
+ thread_set_state, thread_resume, so you should probably do that in
+ HDebugger too, and not call thread_set_state before.
+ <tschwinge> I would hope the GDB code also follows the standard sequence?
+ Can you please check that?
+ <tschwinge> The one thing I'm now confused about is where/how GDB
+ intercepts the standard setup (probably in glibc's signaling mess?) so
+ that it receives any signals raised in the debugged process.
+ <tschwinge> But I'll have to continue later.
+ <hacklu___> tschwinge: thanks for your detail answers. I don't realize that
+ the gnu_resume will resume for handle a signal, much thanks for point
+ this:)
+ <hacklu___> tschwinge: I am not exactly comply with <Mach 3 kernel
+ principles> when I call thread_set_state. but I have called a
+ task_suspend before. I think it's not too bad:)
+ <tschwinge> hacklu___: Yes, but be aware that gnu_resume is only relevant
+ if a signal is to be forwarded to the debugged process (to be handled
+ there), but not for the case where GDB intercepts the signal (such as
+ SIGSEGV), and handles it itself without then forwarding it to the
+ application. See the »info signals« GDB command.
+ <hacklu___> I also confused about when to start the signal thread. I will
+ do more experiment.
+ <hacklu___> I have found this: when the inferior is stop at a breakpoint, I
+ use kill to send a CONT to it, the HDebugger will get this message who
+ listening on the exception port.
+# IRC, freenode, #hurd, 2013-07-28
+ <hacklu_> how to understand the rpctrace output?
+ <hacklu_> like this. 142<--143(pid15921)->proc_mark_stop_request (19 0)
+ 125<--1
+ <hacklu_> 27(pid-1)->msg_sig_post_request (20 5 task108(pid15919));
+ <hacklu_> what is the (pid-1)? the kernel?
+ <teythoon> 1 is /hurd/init
+ <hacklu_> pid-1 not means minus 1?
+ <teythoon> ah, funny, you're right... I dunno then
+ <teythoon> 2 is the kernel though
+ <hacklu_> the 142<--143 is port name?
+ <teythoon> could very well be, but I'm not sure, sorry
+ <hacklu_> the number must be the port name.
+ <teythoon> anyone knows why /hurd/init does not get dead name notifications
+ for /hurd/exec like it does for any other essential server?
+ <teythoon> as far as I can see it successfully asks for them
+ <teythoon> about rpctrace, it poses as the kernel for its children, parses
+ and relays any messages sent over the childrens message port, right?
+# IRC, freenode, #hurd, 2013-07-29
+ <hacklu_> hi. this is my weekly
+ report.
+ <teythoon> hacklu_: the inferior voluntarily stops itself if it gets a
+ signal and notifies its tracer?
+ <hacklu_> yes
+ <teythoon> what if it chose not to do so? undebugable program?
+ <hacklu_> debugged program will be set an flag so called
+ hurdsig_traced. normal program will handle the signal by himself.
+ <hacklu_> in my env, I found that when GDB attach a running program, gdb
+ will not catch the signal send to the program. May help me try it?
+ <teythoon> it doesn't? I'll check...
+ <teythoon> hacklu_: yes, you're right
+ <hacklu_> you can just gdb a loop program, and kill -CONT to it. If I do
+ this I will get "Can't wait for pid 12332:NO child processes" warning.
+ <teythoon> yes, I noticed that too
+ <teythoon> does gdb reparent the tracee?
+ <hacklu_> I don't think this is a good behavior. gdb should get inferior's
+ signal
+ <teythoon> absolutely
+ <hacklu_> In linux it does, not sure about hurd. but I think it should.
+ <teythoon> definitively. there is proc_child in process.defs, but that may
+ only be used once to set the parent of a process
+ <hacklu_> gdb doesn't set the inferior as its child process if attached a
+ running procss in HURD.
+ <tschwinge> hacklu_: So you figured out this tracing/signal stuff. Great!
+ <hacklu_> tschwinge: Hi. not exactly.
+ <hacklu_> as I have mentioned, gdb can't get signal when attach to a
+ running process.
+ <hacklu_> I also want to know how to build glibc in hurd. I have got this "
+ relocation error: ./ symbol _dl_find_dso_for_object, version
+ GLIBC_PRIVATE not defined in file with link time reference" when
+ use LD_PRELOAD=./my_build_glibc/
+ <tschwinge> hacklu: You can't just preload the new, but you'll also
+ need to use the new Have a look at [glibc-build]/ for
+ how to invoke these properly. Or, link with
+ »-Wl,-dynamic-linker=[glibc-build]/elf/,-rpath,[glibc-build]:[glibc-build]/elf
+ -L [glibc-build] -L [glibc-build]/elf«. If using the latter, I suggest
+ to also add »-Wl,-t« to verify that you're linking against the correct
+ libraries, and »ldd
+ <tschwinge> [executable]« to verify that [€xecutable] will load the correct
+ libraries when invoked.
+ <hacklu> I will try that, and I can't find this call
+ pthread_cond_broadcast(). which will called in the proc_mark_stop
+ <tschwinge> hacklu: Oh, right, you'll also need to add libpthread (I think
+ that's the directory name?) to the rpath and -L commands.
+ <hacklu> is libpthread a part of glibc or hurd?
+ <pinotree> glibc
+ <NlightNFotis> hacklu: it is a different repository available here
+ <hacklu> tschwinge: thanks for that, but I don't think I need help about
+ the comiler error now, it just say missing some C file. I will look into
+ the Makefile to verify.
+ <NlightNFotis> but I think it's a part of glibc as a whole
+ <tschwinge> hacklu: OK.
+ <tschwinge> glibc is/was a stand-alone package and library, but in Debian
+ GNU/Hurd is nowadays integrated into glibc's build process.
+ <hacklu> NlightNFotis: thanks. I only add hurd, glibc, gdb,mach code to my
+ cscope file. seems need to add libpthread.
+ <tschwinge> hacklu: If you use the Debian glibc package, our libpthread
+ will be in the libpthread subdirectory.
+ <tschwinge> Ignore nptl, which is used for the Linux kernel.
+ <hacklu> tschwinge:BTW, I have found that, to continue the inferior from a
+ breakpoint, doesn't need to call msg_sig_post_untraced. just call
+ thread_abort and thread_resume is already ok.
+ <hacklu> I get the glibc from
+ <tschwinge> hacklu: That sounds about right, because you want the inferior
+ to continue normally, instead of explicitly sending a (Unix) signal to
+ it.
+ <tschwinge> hacklu: I suggest you use: »apt-get source eglibc« on your Hurd
+ system.
+ <tschwinge> hacklu: The Savannah repository does not yet have libpthread
+ integrated. I have this on my TODO list...
+ <hacklu> tschwinge: no, apt-get source doesn't work in my Hurd. I got any
+ code from git clone ***
+ <pinotree> you most probably lack the deb-src entry in your sources.list
+ <tschwinge> hacklu: Do you have deb-src lines in /etc/apt/source-list? Or
+ how does it fail?
+ <hacklu> tschwinge: I have deb-src lines. and apt-get complain that: E:
+ Unable to find a source package for eglibc or E: Unable to find a source
+ package for glibc
+ <youpi> hacklu: which deb-src lines do you have?
+ <hacklu> and piece of my source_list : deb
+ unreleased main deb-src
+ unreleased main
+ <youpi> you also need a deb-src line with the main archive
+ <youpi> deb-src unstable main
+ <tschwinge> hacklu: Oh, hmm. And you did run »apt-get update« before?
+ That aside, there also is <>
+ that you can use. You'll need the *.dsc and *.debian.tar.xz files
+ corresponbding to your version of glibc, and the *.orig.tar.xz file. And
+ then run »dpkg-source -x *.dsc«.
+ <tschwinge> The Debian snapshot is often very helpful if you need source
+ packages that are no longer in the main Debian repository.
+ <youpi> or simply running dget on the dsc url
+ <tschwinge> Oh. Good to know.
+ <youpi> e.g. dget
+ <hacklu> the network is slowly. and I am in apt-get update.
+ <youpi> I will be away from this evening until sunday, too
+ <hacklu> what the main difference between the source site?
+ <hacklu> is dget means wget?
+ <pinotree> no
+ <hacklu> not exist in linux?
+ <pinotree> it does, in devscripts
+ <pinotree> it's a debian tool
+ <hacklu> oh, yes, I have installed devscripts.
+ <hacklu> I have got the libphread code, thanks.
+ <braunr> teythoon: the simple fact that this msg thread exists to receive
+ requests and that these requests are sent by ps and procfs is a potential
+ DoS
+ <teythoon> braunr: but does that mean that on Hurd a process can prevent a
+ debugger from intercepting signals?
+ <braunr> teythoon: yes
+ <braunr> that's not a problem for interactive programs
+ <braunr> it's part of the hurd design that programs have limited trust in
+ each other
+ <braunr> a user can interrupt his debugger if he sees no activity
+ <braunr> that's more of a problem for non interactive system stuff like
+ init scripts
+ <braunr> or procfs
+ <hacklu> why gdb can't get inferior's signal if attach a running process?
+ <braunr> hacklu: try to guess
+ <hacklu> braunr: it is not a reasonable thing. I always think it should
+ catch the signal.
+ <braunr> hacklu: signals are a unix thing built on top of mach
+ <braunr> hacklu: think in terms of ports
+ <braunr> all communication on the hurd goes through ports
+ <hacklu> but when use gdb to start a process and debugg it, this way, gdb
+ can catch the signal
+ <braunr> hacklu: my guess is :
+ <braunr> when starting a process, gdb can act as a proxy, much like
+ rpctrace
+ <braunr> when attaching, it can't
+ <hacklu> braunr: ah, my question should ask like this: why gdb can't set
+ the inferior as its child process when attaching it? or it can not ?
+ <braunr> hacklu: i'm not sure, the proc server is one of the parts i know
+ the less
+ <braunr> but again, i guess there is no facility to update the msg port of
+ a process in the proc server
+ <braunr> check that before taking it as granted
+ <hacklu> braunr: aha, I alway think you know everything:)
+ <tschwinge> braunr: There is: setmsgport or similar.
+ <braunr> if there is one, gdb doesn't use it
+ <tschwinge> hacklu: That is a good question -- I can't answer it off-hand,
+ but it might be possible (by setting the tracing flag, and such things).
+ Perhaps it's just a GDB bug, which omits to do that. Perhaps just a
+ one-line code change, perhaps not. That's a new bug (?) report that we
+ may want to have a look at later on.
+ <tschwinge> hacklu: But also note, this new problem is not really related
+ to your gdbserver work -- but of course you're fine to have a look at it
+ if you'd like to.
+ <hacklu> I just to ask for whether this is a normal behavior. this is
+ related to my gdbserver work, as gdbserver also need to attach a running
+ process...
+ <braunr> gdbserver can start a process just like gdb does
+ <braunr> you may want to focus on that first
+ <tschwinge> Yes.
+ <tschwinge> Attaching to processes that are already running is, I think,
+ always more complicated compared to the case where GDB/gdbserver has
+ complete control about the inferior right from the beginning.
+ <hacklu> yes, I am only focus on start one. the attach way I haven't
+ research now.
+ <tschwinge> hacklu: That's totally fine. You can just say that attaching
+ to processes is not supported yet.
+ <hacklu> that's sound good:)
+ <tschwinge> Ther will likely be more things in gdbserver that you won't be
+ able to easily support, so it's fine to do it step-by-step.
+ <tschwinge> And then later add more features incrementally.
+ <tschwinge> That's also easier for reviewing the patches.
+ <hacklu> and one more question I have ask yestoday. what is the rpctrace
+ output (pid-1) mean?
+ <tschwinge> hacklu: Another thing I can't tell off-hand. I'll try to look
+ it up.
+ <teythoon> hacklu, tschwinge: my theory is that it is in fact an error
+ message, maybe the proc server did not now a pid for the task
+ <braunr> hacklu: utsl
+ <hacklu> tschwinge: for saving your time, I will look the code myself, I
+ don;t think this is a real hard question need you to help me by reading
+ the source code.
+ <tschwinge> teythoon, hacklu: Yes, from a quick inspection it looks like
+ task2pid returning a -1 PID -- but I can't tell yet what that is supposed
+ to mean, if it's an actualy bug, or just means there is no data
+ available, or similar.
+ <hacklu> braunr: utsl??
+ <tschwinge> hacklu:
+ <hacklu> tschwinge: thank you. braunr like say abbreviation which I can't
+ google out.
+ <tschwinge> hacklu: Again, if this affects your work, it is fine to have a
+ look at that presumed rpctrace problem, if not, it is fine to have a look
+ at it if you'd like to, and otherwise, we'll file it as a possible bug to
+ be looked at laster.
+ <tschwinge> hacklu: Now you learned that one. :-)
+ <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will
+ figure out it.
+ <teythoon> btw, what about the copyright assignment process?
+ <tschwinge> teythoon, hacklu: You still haven't heard from the FSF about
+ your copyright assignments? What's the latest you have heard?
+ <hacklu> tschwinge: I have wrote a emali to ask for that, but no reply.
+ <teythoon> tschwinge: last and only response I got was on July 1st, the
+ last ping with explicit request for confirmation was on July the 12th
+ <tschwinge> hacklu: When did you send this email?
+ <hacklu> tschwinge: last week.
+ <tschwinge> teythoon: I suggest you send another inquiry, and please put me
+ in CC. And if there'S no answer within a couple days (well, I'm away
+ until Monday...), I'll follow up.
+ <tschwinge> hacklu: Likewise for you; depending on when exactly ;-) you
+ sent the last email. (Always allow for a few days until you exect an
+ answer, but if nothing happend within a week for such rather simple
+ administrative tasks, better ask again, unfrotunately.)
+ <hacklu> tschwinge:ok , I will email more
+ <hacklu> how to understand the asyn RPC?
+ <braunr> hacklu: hm ?
+ <hacklu> for instance, [hurd]/proc/main.c proc_server is loop in listening
+ message. and handle it by message_demuxer.
+ <hacklu> but when I send a request like proc_wait_request() to it, will it
+ block in the message_demuxer?
+ <hacklu> and where is the function of
+ ports_manage_port_operations_multithread()?
+ <braunr> this one is in libports
+ <braunr> it's the last thing a server calls after bootstrapping itself
+ <braunr> message_demuxer normally blocks, yes
+ <braunr> but it's not "async"
+ <hacklu> the names seems the proc_server is listening message with many
+ threads?
+ <braunr> every server in the hurd does
+ <braunr> threads are created by ports_manage_port_operations_multithread
+ when incoming messages can't be processed quick enough by the set of
+ already existing threads
+ <hacklu> if too many task send request to the server, will it ddos?
+ <braunr> yes
+ <teythoon> every server but /hurd/init
+ <braunr> (and /hurd/hello)
+ <braunr> hacklu: that's, in my opinion, a major design defect
+ <hacklu> yes, that is reasonable.
+ <braunr> that's what causes what i like to call thread storms on message
+ floods ... :)
+ <braunr> my hurd clone is intended to address such major issues
+ <teythoon> couldn't that be migitated by some kind of heuristic?
+ <braunr> it already is ..
+ <hacklu> I don't image that the port_manage_port_operations_multithread
+ will dynamically create threads. I thought the server will hang if all
+ work thread is in use.
+ <braunr> that would also be a major defect
+ <braunr> creating as many threads as necessary is a good thing
+ <braunr> the problem is the dos
+ <braunr> hacklu: btw, ddos is "distributed" dos, and it doesn't really
+ apply to what can happen on the hurd
+ <hacklu> why not ? as far as I known, the message transport is
+ transparent. hurd has the chance to be DDOSed
+ <braunr> we don't care about the distributed property of the dos
+ <hacklu> oh, I know what you mean.
+ <braunr> it simply doesn't matter
+ <braunr> on thread calling select in an event loop with a low timeout (high
+ frequency) on a bunch of file descriptors is already enough to generate
+ many dead-name notifications
+ <tschwinge> Oh! Based on what I've read in GDB source code, I thought the
+ proc server was single-threaded. However, it no longer is, after 1996's
+ Hurd commit fac6d9a6d59a83e96314103b3181f6f692537014.
+ <braunr> those notifications cause message flooding at servers (usually
+ pflocal/pfinet), which spawn a lot of threads to handle those messages
+ <braunr> one* thread
+ <hacklu> tschwinge: ah, the comment in gnu_nat.c is out of date!
+ <braunr> hacklu: and please, please, clean the hello_world processes you're
+ creating on darnassus
+ <braunr> i had to do it myself again :/
+ <hacklu> braunr: [hacklu@darnassus ~]$ ps ps: No applicable processes
+ <braunr> ps -eflw
+ <braunr> htop
+ <tschwinge> hacklu: Probably the proc_wait_pid and proc_waits_pending stuff
+ could be simplified then? (Not an urgent issue, of course, will file as
+ an improvement for later.)
+ <hacklu> braunr: ps -eflw |grep hacklu
+ <hacklu> 1038 12360 10746 26 26 2 87 22 148M 1.06M 97:21001 S
+ p1 0:00.00 grep --color=auto hacklu
+ <braunr> 15:08 < braunr> i had to do it myself again :/
+ <teythoon> braunr: so as a very common special case, a lot of dead name
+ notifications cause problems for pf*?
+ <braunr> and use your numeric uid
+ <braunr> teythoon: yes
+ <hacklu> braunr: I am so sorry. I only used ps to check. forgive me
+ <braunr> teythoon: simply put, a lot of messages cause problems
+ <braunr> select is one special use case
+ <teythoon> braunr: blocking other requests?
+ <braunr> the other is page cache writeback
+ <braunr> creating lots of threads
+ <braunr> potentially deadlocking on failure
+ <braunr> and in the case of writebacks, simply starving
+ <teythoon> braunr: but dead name notifications should mostly trigger
+ cleanup actions, couldn't those be handled by a different thread(pool)
+ than the rest?
+ <braunr> that's why you can bring down a hurd system with a simple cp
+ bigfile somewhere, bigfile being a few hundreds MiBs
+ <braunr> teythoon: it doesn't change the problem
+ <braunr> threads are per task
+ <braunr> and the contention would remain the same
+ <teythoon> hm
+ <braunr> since dead-name notifications are meant to release resources
+ created by what would then be "regular" threads
+ <braunr> don't worry, there is a solution
+ <braunr> it's simple
+ <braunr> it's well known
+ <braunr> it's just hard to directly apply to the hurd
+ <braunr> and impossible to enforce on mach
+ <hacklu> tschwinge: I am confuzed after I have look into S_proc_wait()
+ [hurd/proc/wait.c], it has relate pthread_hurd_cond_wait_np. I can't find
+ out when it will return. And the signal is report to the debuger by
+ S_proc_wait.
+ <teythoon> braunr: a pointer please ;)
+ <braunr> teythoon: basically, synchronous ipc
+ <braunr> then, enforcing one server thread per client thread
+ <braunr> and replace mach-generated notifications with messages sent from
+ client threads
+ <braunr> the only kind of notification required by the hurd are no-senders
+ notifications
+ <braunr> this happens when a client releases all references it has to a
+ resource
+ <braunr> so it's easy to make that synchronous as well
+ <braunr> trying to design RPCs as closely as system calls on monolithic
+ kernels helps in viewing how this works
+ <braunr> the only real additions are address space crossing, and capability
+ invocation
+ <teythoon> sounds reasonable, why is it hard to apply to the hurd? most
+ rpcs are synchonous, no?
+ <braunr> mach ipc isn't
+ <hacklu> braunr: When client C send a request to server S, but doesn't wait
+ for the reply message right now, for a while, C call mach_msg to recieve
+ reply. Can I think this is a synchronous RPC?
+ <braunr> a malicious client can still overflow message queues
+ <braunr> hacklu: no
+ <teythoon> yes, I can see how this is impossible to enforce, but still we
+ could all try to play nice :)
+ <braunr> teythoon: no
+ <braunr> :)
+ <braunr> async ipc is heavy, error-prone, less performant than sync ipc
+ <braunr> some async ipc is necessary to handle asynchronous events, but
+ something like unix signals is actually a lot more appropriate
+ <braunr> we're diverging from the gsoc though
+ <braunr> don't waste too much time on that
+ <teythoon> 15:13 < braunr> it's just hard to directly apply to the hurd
+ <teythoon> I wont
+ <teythoon> why is it hard
+ <braunr> almost everything is synchronous on the hurd
+ <braunr> except a few critical bits
+ <braunr> signals :)
+ <braunr> and select
+ <braunr> and pagecache writebacks
+ <braunr> fixing those parts require some work
+ <braunr> which isn't trivial
+ <braunr> for example, select should be rewritten not to use dead-name
+ notifications
+ <teythoon> adding a light weight signalling mechanism to mach and using
+ that instead of async ipc?
+ <braunr> instead of destroying ports once an event has been received, it
+ should (synchyronously) remove the requests installed at remote servers
+ <braunr> uh no
+ <braunr> well maybe but that would be even harder
+ <tschwinge> hacklu: This (proc/wait.c) is related to POSIX thread
+ cancellation -- I don't think you need to be concerned about that. That
+ function's "real" exit points are earlier above.
+ <braunr> teythoon: do you understand what i mean about select ?
+ <teythoon> ^^ is that a no go area?
+ <braunr> for now it is
+ <braunr> we don't want to change the mach interface too much
+ <teythoon> yes, I get the point about select, but I haven't looked at its
+ implementation yet
+ <hacklu> tschwinge: when I want to know the child task's state, I call
+ proc_wait_request(), unless the child's state not change. the
+ S_proc_wait() will not return?
+ <braunr> it creates ports, puts them in a port set, gives servers send
+ rights so they can notify about events
+ <teythoon> y not? it's not that hurd is portable to another mach, or is it?
+ and is there another that we want to be compatible with?
+ <braunr> when an event occurs, all ports are scanned
+ <braunr> then destroyed
+ <braunr> on destruction, servers are notified by mach
+ <braunr> the problem is that the client is free to continue and make more
+ requests while existing select requests are still being cancelled
+ <teythoon> uh, yeah, that sounds like a costly way of notifying somewone
+ <braunr> the cost isn't the issue
+ <braunr> select must do something like that on a multiserver system, you
+ can't do much about it
+ <braunr> but it should be synchronous, so a client can't make more requests
+ to a server until the current select call is complete
+ <braunr> and it shouldn't use a server approach at the client side
+ <braunr> client -> server should be synchronous, and server -> client
+ should be asynchronous (e.g. using a specific SIGSELECT signal like qnx
+ does)
+ <braunr> this is a very clean way to avoid deadlocks and denials of service
+ <teythoon> yes, I see
+ <braunr> qnx actually provides excellent documentation about these issues
+ <braunr> and their ipc interface is extremely simple and benefits from
+ decades of experience on the subject
+ <tschwinge> hacklu: This function implements the POSIX wait call, and per
+ »man 2 wait«: »The wait() system call suspends execution of the calling
+ process until one of its children terminates.«
+ <tschwinge> hacklu: This is implemented in glibc in sysdeps/posix/wait.c,
+ sysdeps/unix/bsd/bsd4.4/waitpid.c, sysdeps/mach/hurd/wait4.c, by invoking
+ this RPC synchronously.
+ <tschwinge> hacklu: GDB on the other hand, uses this infrastructure (as I
+ understand it) to detect (that is, to be informed) when a debuggee exits
+ (that is, when the inferior process terminates).
+ <tschwinge> hacklu: Ah, so maybe I miss-poke earlier: the
+ pthread_hurd_cond_wait_np implements the blocking. And depending on its
+ return value the operation will be canceled or restarted (»start_over«).
+ <tschwinge> s%maybe%%
+ <tschwinge> hacklu: Does this information help?
+ <hacklu> tschwinge: proc_wait_request is not only to detect the inferior
+ exit. it also detect the child's state change
+ <braunr> as tschwinge said, it's wait(2)
+ <hacklu> tschwinge: and I have see this, when kill a signal to inferior,
+ the gdb will get the message id=24120 which come from S_proc_wait
+ <hacklu> braunr: man 2 wait says: wait, waitpid, waitid - wait for process
+ to change state. (in linux, in hurd there is no man wait)
+ <braunr> uh
+ <braunr> there is, it's the linux man page :)
+ <braunr> make sure you have manpages-dev installed
+ <hacklu> I always think we are talk about linux's manpage :/
+ <hacklu> but regardless the manpage, gdb really call proc_wait_request() to
+ detect whether inferior's changed states
+ <braunr> in any case, keep in mind the hurd is intended to be a posix
+ system
+ <braunr> which means you can always refer to what wait is expected to do
+ from the posix spec
+ <braunr> see
+ <hacklu> braunr: even in the manpags under hurd, man 2 wait also says: wait
+ for process to change state.
+ <braunr> yes
+ <braunr> that's what it's for
+ <braunr> what's the problem ?
+ <hacklu> the problem is what tschwinge has said I don't understand. like
+ and per »man 2 wait«: »The wait() system call suspends execution of the
+ calling process until one of its children terminates.«
+ <braunr> terminating is a form of state change
+ <braunr> historically, wait was intended to monitor process termination
+ only
+ <hacklu> so the thread become stoped wait also return
+ <braunr> afterwards, process tracing was added too
+ <braunr> what ?
+ <hacklu> so when the child state become stopped, the wait() call will
+ return?
+ <braunr> yes
+ <hacklu> and I don't know this pthread_hurd_cond_wait_np.
+ <braunr> wait *blocks* until the process it references changes state
+ <braunr> pthread_hurd_cond_wait_np is the main blocking function in hurd
+ servers
+ <braunr> well, pthread_hurd_cond_timedwait_np actually
+ <braunr> all blocking functions end up there
+ <braunr> (or in mach_msg)
+ <braunr> (well pthread_hurd_cond_timedwait_np calls mach_msg too)
+ <hacklu> since I use proc_wait_request to get the state change, so the
+ thread in proc_server will be blocked, not me. is that right?
+ <braunr> no
+ <braunr> both
+ <hacklu> this is just a request, why should block me?
+ <braunr> because you're waiting for the reply afterwards
+ <braunr> or at least, you should be
+ <braunr> again, i'm not familiar with those parts
+ <hacklu> after call proc_wait_request(), gdb does a lot stuffs, and then
+ call mach_msg to recieve reply.
+ <braunr> ok
+ <hacklu> I think it will be blocked only in mach_msg() if need.
+ <braunr> usually, xxx_request are the async send-only versions of RPCs
+ <tschwinge> Yes, that'S my understanding too.
+ <braunr> and xxx_reply the async receive-only
+ <braunr> so that makes sense
+ <hacklu> so I have ask you is it a asyn RPC.
+ <braunr> yes
+ <braunr> 15:18 < hacklu> braunr: When client C send a request to server S,
+ but doesn't wait for the reply message right now, for a while, C call
+ mach_msg to recieve reply. Can I think this is a synchronous RPC?
+ <braunr> 15:19 < braunr> hacklu: no
+ <braunr> if it's not synchronous, it's asynchronous
+ <hacklu> sorry, I spell wrong. missing a 'a' :/
+ <tschwinge> S_proc_wait_reply will then be invoked once the procserver
+ actually answers the "blocking" proc_wait call.
+ <tschwinge> Putting "blocking" in quotes, because (due to the asyncoronous
+ RPC invocation), GDB has not actually blocked on this.
+ <braunr> well, it doesn't call proc_wait
+ <hacklu> tschwinge: yes, the S_proc_wait_reply is called by
+ process_reply_server().
+ <hacklu> tschwinge: so the "blocked" one is the thread in proc_server .
+ <tschwinge> braunr: Right. »It requests the proc_wait service.«
+ <braunr> gdb will also block on mach_msg
+ <braunr> 16:05 < braunr> both
+ <hacklu> braunr: yes, if gdb doesn't call mach_msg to recieve reply it will
+ not be blocked.
+ <braunr> i expect it will always call mach_msg
+ <braunr> right ?
+ <hacklu> braunr: yes, but before it call mach_msg, it does a lot other
+ things. but finally will call mach_msg
+ <braunr> that's ok
+ <braunr> that's the kind of things asynchronous IPC allows
+ <hacklu> tschwinge: I have make a mistake in my week report. The signal
+ recive by inferior is notified by the proc_server, not the
+ send_signal. Because the send_singal send a SIGCHLD to gdb's msgport not
+ gdbself. That make sense.
+# IRC, freenode, #hurd, 2013-07-30
+ <hacklu> braunr: before I go to sleep last night, this question pop into my
+ mind. How do you find my hello_world is still alive on darnassus? The
+ process is not a CPU-heavy or IO-heavy guy. You will not feel any
+ performance penalization. I am so curious :)
+ <teythoon> hacklu: have you looked into patching the proc server to allow
+ reparenting of processes?
+ <hacklu> teythoon:not yet
+ <teythoon> hacklu: i've familiarized myself with proc in the last week,
+ this should get you started nicely:
+ diff --git a/proc/mgt.c b/proc/mgt.c
+ index 7af9c1a..a11b406 100644
+ --- a/proc/mgt.c
+ +++ b/proc/mgt.c
+ @@ -159,9 +159,12 @@ S_proc_child (struct proc *parentp,
+ if (!childp)
+ return ESRCH;
+ + /* XXX */
+ if (childp->p_parentset)
+ return EBUSY;
+ + /* XXX if we are reparenting, check permissions. */
+ +
+ mach_port_deallocate (mach_task_self (), childt);
+ /* Process identification.
+ @@ -176,6 +179,7 @@ S_proc_child (struct proc *parentp,
+ childp->p_owner = parentp->p_owner;
+ childp->p_noowner = parentp->p_noowner;
+ + /* XXX maybe need to fix refcounts if we are reparenting, not sure */
+ ids_rele (childp->p_id);
+ ids_ref (parentp->p_id);
+ childp->p_id = parentp->p_id;
+ @@ -183,11 +187,14 @@ S_proc_child (struct proc *parentp,
+ /* Process hierarchy. Remove from our current location
+ and place us under our new parent. Sanity check to make sure
+ parent is currently init. */
+ - assert (childp->p_parent == startup_proc);
+ + assert (childp->p_parent == startup_proc); /* XXX */
+ if (childp->p_sib)
+ childp->p_sib->p_prevsib = childp->p_prevsib;
+ *childp->p_prevsib = childp->p_sib;
+ + /* XXX we probably want to keep a reference to the old
+ + childp->p_parent around so that if the debugger dies or detaches,
+ + we can reparent the process to the old parent again */
+ childp->p_parent = parentp;
+ childp->p_sib = parentp->p_ochild;
+ childp->p_prevsib = &parentp->p_ochild;
+ <teythoon> the code doing the reparenting is already there, but for now it
+ is only allowed to happen once at process creation time
+ <hacklu> teythoon: good job. This is in my todo list, when I implement
+ attach feature to gdbserver I will need this
+ <braunr> hacklu: i use htop
+ <teythoon> braunr: why is that process so disruptive?
+ <braunr> the big problem with those stale processes is that they're in a
+ state that prevents one important script to complete
+ <braunr> there is a bug on the hurd with regard to terminals
+ <braunr> when you log out of an ssh session, the terminal remains open for
+ some reason (bad reference counting somewhere, but it's quite tricky to
+ identify)
+ <braunr> to work around the issue, i have a cron job that calls a script to
+ kill unused terminals
+ <braunr> this works by listing processes
+ <braunr> your hello_world processes block that listing
+ <teythoon> uh, how so?
+ <hacklu> braunr: ok. I konw.
+ <braunr> teythoon: probably the denial of service we were talking about
+ yesterday
+ <teythoon> select flooding a server?
+ <braunr> no, a program refusing to answer on its msg port
+ <braunr> ps has an option -M :
+ <braunr> -M, --no-msg-port Don't show info that uses a process's
+ msg port
+ <braunr> the problem is that my script requires those info
+ <teythoon> ah, I see, right
+ <braunr> hacklu being working on gdb, it's not surprising he's messing with
+ that
+ <teythoon> yes indeed. couldn't ps use a timeout to detect that?
+ <hacklu> braunr: yes, once I have found ps will hang when I has run
+ hello_world in a breakpoint state.
+ <teythoon> braunr: thanks for explaining the issue, i always wondered why
+ that process is such big a deal ;)
+ <braunr> teythoon: how do you tell between processes being slow to answer
+ and intentionnally refusing to answer ?
+ <braunr> a timeout is almost never the right solution
+ <braunr> sometimes it's the only solution though, like for networking
+ <braunr> but on a system running on a local machine, there is usually
+ another way
+ <teythoon> braunr: I don't of course
+ <braunr> ?
+ <braunr> ah ok
+ <braunr> it was rethorical :)
+ <teythoon> yes I know, and I was implying that I wasn't expecting a timeout
+ to be the clean solution
+ <teythoon> and the current behaviour is hardly acceptable
+ <braunr> i agree
+ <braunr> it's ok for interactive cases
+ <braunr> you can use Ctrl-C, which uses a 3 seconds delay to interrupt the
+ client RPC if nothing happens
+ <teythoon> braunr: btw, what about *_reply.defs? Should I add a
+ corresponding reply simpleroutine if I add a routine?
+ <braunr> normally yes
+ <braunr> right, forgot about that
+ <teythoon> so that the procedure ids are kept in sync in case one wants to
+ do this async at some point in the future?
+ <braunr> yes
+ <braunr> this happened with select
+ <braunr> i had to fix the io interface
+ <teythoon> ok, noted
+# IRC, freenode, #hurd, 2013-07-31
+ <hacklu> Do we need write any other report for the mid-evaluation? I have
+ only submit a question-answer to google.
+# IRC, freenode, #hurd, 2013-08-05
+ <hacklu> hi, this is my weekly
+ report.
+ <hacklu> youpi: can you show me some suggestions about how to design the
+ interface and structure of gdbserver?
+ <youpi> hacklu: well, I've read your blog entry, I was wondering about
+ tschwinge's opinion, that's why I asked whether he was here
+ <youpi> I would tend to start from an existing gdbserver, but as I haven't
+ seen the code at all, I don't know how much that can help
+ <hacklu> so you mean I shoule get a worked gdbserver then to improve it?
+ <youpi> I'd say so, but again it's not a very strong opinion
+ <youpi> I'd rather let tschwinge comment on this
+ <hacklu> youpi: ok :)
+ <youpi> how about the copyright assignments? did hacklu or teythoon receive
+ any answer?
+ <teythoon> youpi: I did, the copyright clerk told me that he finally got my
+ papers and that everything is in order now
+ <youpi> few!
+ <youpi> s/f/ph
+ <youpi> teythoon: you mean all steps are supposed to be done now, or is he
+ doing the last steps? I don't see your name in the copyright folder yet
+ <teythoon> youpi: well, he said that he had the papers and they are about
+ to be signed
+ <youpi> teythoon: ok, so it's not finished, that's why your name is not on
+ the list yet
+ <youpi> this paper stuff is really a pain
+ <hacklu> youpi: I haven't got any answer from FSF now.
+ <youpi> did you ping them recently?
+ <hacklu> I have pinged 2 week ago.
+ <hacklu> what you mean of ping? I just write an email to him. Is it enough?
+ <youpi> yes
+# IRC, freenode, #hurd, 2013-08-12
+ <hacklu> hi, this is my weekly report
+ . sorry for so late.
+ <youpi> hacklu: it seems we misunderstood ourselves last week, I meant to
+ start from the existing gdbserver implementation
+ <youpi> but never mind :)
+ <youpi> starting from the lynxos version was a good idea
+ <hacklu> youpi: em... yeah, the lynxos port is so clean and simple.
+ <hacklu> youpi: aha, the "Remote connection closed" problem has been fixed
+ after I add a init_registers_i386() and set the structure target_desc.
+ <hacklu> but I don't get understand with the structure target_desc. I only
+ know it is auto-generated which configured by the configure.srv.
+ <tschwinge> Hi!
+ <tschwinge> hacklu: In gdbserver, you should definitely re-use existing
+ infrastructure, especially anything that deals with the
+ protocol/communication with GDB (that is, server.c and its support
+ files).
+ <tschwinge> hacklu: Then, for the x86 GNU Hurd port, it should be
+ implemented in the same way as an existing port. The Linux port is the
+ obvious choice, of course, but it is also fine to begin with something
+ simpler (like the LynxOS port you've chosen), and then we can still add
+ more features later on. That is a very good approach actually.
+ <tschwinge> hacklu: The x86 GNU Hurd support will basically consist of
+ three pieces -- exactly as with GDB's native x86 GNU Hurd port: x86
+ processor specific (tge existing gdbserver/i386-low.c etc. -- shouldn't
+ need any modifications (hopefully)), GNU Hurd specific
+ (gdbserver/gnu-hurd-low.c (or similar)), and x86 GNU Hurd specific
+ (gdbserver/gnu-hurd-x86-low.c (or similar)).
+ <tschwinge> s%tge%the
+ <hacklu> tschwinge: now I have only add a file named gnu-low.c, I should
+ move some part to the file gnu-i386-low.c I think.
+ <tschwinge> hacklu: That's fine for the moment. We can move the parts
+ later (everything with 86 in its name, probably).
+ <hacklu> that's ok.
+ <hacklu> tschwinge: Can I copy code from gnu-nat.c to
+ gdbserver/gnu-hurd-low.c? I think the two file will have many same code.
+ <tschwinge> hacklu: That's correct. Ideally, the code should be shared
+ (for example, in a file in common/), but that's an ongoing discussion in
+ GDB, for other duplicated code. So, for the moment, it is fine to copy
+ the parts you need.
+ <tschwinge> hacklu: Oh, but it may be a good idea to add a comment to the
+ source code, where it is copied from.
+ <hacklu> maybe I can do a common-part just for hurd gdb port.
+ <tschwinge> That should make it easier later on, to consolidate the
+ duplicated code into one place.
+ <tschwinge> Or you can do that, of course. If it's not too difficult to
+ do?
+ <hacklu> I think at the begining it is not difficult. But when the
+ gdbserver code grow, the difference with gdb is growing either. That will
+ be too many #if else.
+ <tschwinge> I think we should check with the GDB maintainers, what they
+ suggest.
+ <tschwinge> hacklu: Please send an email To: <> Cc:
+ <>, <>, and ask about
+ this: you need to duplicate code that already exists in gnu-nat.c for new
+ gdbserver port -- how to share code?
+ <hacklu> tschwinge: ok, I will send the email right now.
+ <hacklu> tschwinge: need I cc to hurd mail-list?
+ <tschwinge> hacklu: Not really for that questions, because that is a
+ question only relevant to the GDB source code itself.
+ <hacklu> tschwinge: got it.
+# IRC, freenode, #hurd, 2013-08-19
+ <hacklu__> when and where is the best time and place to get the regitser
+ value in gdb?
+ <youpi> well, I'm not sure to understand the question
+ <youpi> you mean in the gdb source code, right?
+ <youpi> isn't it already done in gdb?
+ <youpi> probably similarly to i386?
+ <youpi> (linux i386 I mean)
+ <hacklu__> I don't find the fetch_register or relate function implement in
+ gnu-nat.c
+ <hacklu__> so I can't make decision how to implement this in gdbserver.
+ <youpi> it's in i386gnu-nat.c, isn't it?
+ <hacklu__> yeah.
+ <youpi> does that answer your issue?
+ <hacklu__> thank you. I am so stupid
+# IRC, freenode, #hurd, 2013-08-26
+ < hacklu> hello everyone, this is my week
+ report.
+ < hacklu> btw, my FSF copyright assignment has been concepted. They guy
+ said, they have recived my mail for a while but forget to handle it.
+ < hacklu> but now I face a new problem, when I typed the first continue
+ command, gdb will continue all the breakpoint, and the inferior will run
+ until normally exit.
+# IRC, freenode, #hurd, 2013-08-30
+ <hacklu> tschwinge: hi, does gdb's attach feature work correctlly on Hurd?
+ <hacklu> on my hurd-box, the gdb can't attach to a running process, after a
+ attaching, when I continue, gdb complained "can't find pid 12345"
+ <teythoon> hacklu: attaching works, not sure why gdb is complaining
+ <hacklu> teythoon: yeah, it can attaching, but can't contine process.
+ <hacklu> in this case, the debugger is useless if it can't resume execution
+ <teythoon> hacklu: well, gdb on Linux reacts a little differently, but for
+ me attaching and then resuming works
+ <hacklu> teythoon: yes, gdb on linux works well.
+ <teythoon> % gdb --pid 21506 /bin/sleep
+ <teythoon> [...]
+ <teythoon> (gdb) c
+ <teythoon> Continuing.
+ <teythoon> warning: Can't wait for pid 21506: No child processes
+ <teythoon> # pkill -SIGILL sleep
+ <teythoon> warning: Pid 21506 died with unknown exit status, using SIGKILL.
+ <hacklu> yes. I used a sleep program to test too.
+ <teythoon> I believe that the warning and deficiencies with the signal
+ handling are b/c on Hurd the debuggee cannot be reparented to the
+ debugger
+ <hacklu> oh, I remembered, I have asked this before.
+ <tschwinge> Confirming that attaching to a process in __sleep -> __mach_msg
+ -> mach_msg_trap works fine, but then after »continue«, I see »warning:
+ Can't wait for pid 4038: No child processes« and three times »Can't fetch
+ registers from thread bogus thread id 1: No such thread« and the sleep
+ process exits (normally, I guess? -- interrupted "system call").
+ <tschwinge> If detaching (exit GDB) instead, I see »warning: Can't modify
+ tracing state for pid 4041: No such process« and the sleep process exits.
+ <tschwinge> Attaching to and then issueing »continue« in a process that is
+ not currently in a mach_msg_trap (tested a trivial »while (1);«) seems to
+ work.
+ <tschwinge> hacklu: ^
+ <hacklu> tschwinge: in my hurdbox, if I just attach a while(1), the system
+ is near down. nothing can happen, maybe my hardware is slow.
+ <hacklu> so I can only test on the sleep one.
+ <hacklu> my gdbserver doesn't support attach feature now. the other basic
+ feather has implement. I am doing test and review the code now.
+ <tschwinge> Great! :-)
+ <tschwinge> It is fine if attaching does not work currently -- can be added
+ later.
+ <hacklu> btw, How can I submit my code? put the patch in email directly?
+ <tschwinge> Did you already run the GDB testsuite using your gdbserver?
+ <hacklu> no, haven't yet
+ <tschwinge> Either that, or a Git branch to pull from.
+ <hacklu> I think I should do more review and test than I submit patches.
+ <tschwinge> hacklu: See [GDB]/gdb/testsuite/boards/native-gdbserver.exp
+ (and similar files) for how to run the GDB testsuite with gdbserver.
+ <hacklu> ok.
+ <tschwinge> But don't be disappointed if there are still a lot of failures,
+ etc. It'll already be great if some basic stuff works.
+ <hacklu> now it can set and remove breakpoint. show register, access
+ variables.
+ <tschwinge> ... which already is enogh for a lot of debugging sessions.
+ :-)
+ <hacklu> I will continue to make it more powerful.
+ <hacklu> :)
+ <tschwinge> Yes, but please first work on polishing the existing code, and
+ get it integrated upstream. That will be a great milestone.
+ <tschwinge> No doubt that GDB maintainers will have lots of comments about
+ proper formatting of the source code, and such things. Trivial, but will
+ take time to re-work and get right.
+ <hacklu> oh, I got it. I will give my pathch before this weekend.
+ <tschwinge> Then once your basic gdbserver is included, you can continue to
+ implement additional features, piece by piece.
+ <tschwinge> And then we can run the GDB testsuite with gdbserver and
+ compare that there are no regressions, etc.
+ <tschwinge> Heh, »before the weekend« -- that's soon. ;-)
+ <hacklu> honestly to say, most of the code is copyed from other files, I
+ haven't write too many code myself.
+ <tschwinge> Good -- this is what I hoped. Often, more time in software
+ development is spent on integrating existing things rathen than writing
+ new code.
+ <hacklu> but I have spent a lot of time to get known the code and to debug
+ it to work.
+ <tschwinge> Thzis is normal, and is good in fact: existing code has already
+ been tested and documented (in theory, at least...).
+ <tschwinge> Yes, that's expected too: when relying on/reusing existing
+ code, you first have to understand it, or at least its interfaces. Doing
+ that, you're sort of "mentally writing the existing code again".
+ <tschwinge> So, this sounds all fine. :-)
+ <hacklu> your words make me happy.
+ <hacklu> :)
+ <tschwinge> Well, I am, because this seems to be going well.
+ <hacklu> thank you. I am going to coding now~~
+# IRC, freenode, #hurd, 2013-09-02
+ <hacklu> hi, this is my weekly
+ report.
+ <hacklu> please give me any advice on how to use mig to generate stub-files
+ in gdbserver?
+ <braunr> hacklu:
+ <hacklu> braunr: shouldnt' I work like this
+ ?
+ <braunr> hacklu: seems that you need server code
+ <braunr> other than that i don't see the difference
+ <hacklu> gdb use autoconf to generate the Makefile, and part from the *.mh
+ file, but in gdbserver, there is no .mh like files.
+ <braunr> hacklu: why can't you reuse / ?
+ <hacklu> braunr: question is that, there are something not need in
+ /
+ <braunr> hacklu: like what ?
+ <hacklu> braunr: like fork-child.o msg_U.o core-regset.o
+ <braunr> hacklu: well, adjust the dependencies as you need
+ <braunr> hacklu: do you mean they become useless for gdbserver but are
+ useful for gdb ?
+ <hacklu> braunr: yes, so I need another one file.
+ <hacklu> braunr: but the gdbserver's configure doesn't have any *.mh file,
+ can I add the first one?
+ <braunr> or adjust the values of those variables depending on the building
+ mode
+ <braunr> maybe
+ <braunr> tschwinge is likely to better answer those questions
+ <hacklu> braunr: ok, I will wait for tschwinge's advice.
+ <luisgpm> hacklu, The gdb/config/ dir is for files related to the native
+ gdb builds, as opposed to a cross gdb that does not have any native bits
+ in it. In the latter, gdbserver will be used to touch the native layer,
+ and GDB will only guide gdbserver through the debugging session...
+ <luisgpm> hacklu, In case you haven't figured that out already.
+ <hacklu> luisgpm: I am not very clear with you. According to your words, I
+ shouldn't use gdb/config for gdbserver?
+ <luisgpm> hacklu, Correct. You should use configure.srv for gdbserver.
+ <luisgpm> hacklu, gdb/gdbserver/configure.srv that is.
+ <luisgpm> hacklu, gdb/configure.tgt for non-native gdb files...
+ <luisgpm> hacklu, and gdb/config for native gdb files.
+ <luisgpm> hacklu, The native/non-native separation for gdb is due to the
+ possibility of having a cross gdb.
+ <congzhang> what's srv file purpose?
+ <luisgpm> hacklu, gdbserver, on the other hand, is always native.
+ <luisgpm> Doing the target-to-object-files mapping.
+ <hacklu> how can I use configure.srv to config the MIG to generate
+ stub-files?
+ <luisgpm> What are stub-files in this context?
+ <hacklu> On Hurd, some rpc stub file are auto-gen by MIG with *.defs file
+ <braunr> luisgpm: c source code handling low level ipc stuff
+ <braunr> mig is the mach interface generator
+ <tschwinge> luisgpm, hacklu: If that is still helpful by now, in
+ <>
+ I described the MIG usage in GDB. (Which also states that ptrace is a
+ system call which it is not.)
+ <tschwinge> hacklu: For the moment, it is fine to indeed copy the rules
+ related to MIG/RPC stubs from gdb/config/i386/ to a (possibly
+ new) file in gdbserver. Then, later, we should work out how to properly
+ share these, as with all the other code that is currently duplicated for
+ GDB proper and gdbserver.
+ <luisgpm> hacklu, tschwinge: If there is code gdbserver and native gdb can
+ use, feel free to put them inside gdb/common for now.
+ <tschwinge> hacklu, luisgpm: Right, that was the conclusion from
+ <>.
+ <hacklu> tschwinge, luisgpm : ok, I got it.
+ <hacklu> tschwinge: sorry for haven't submit pathes yet, I will try to
+ submit my patch tomorrow.
+[[!message-id ""]].
+# IRC, freenode, #hurd, 2013-09-06
+ <hacklu> If I want compile a file which is not in the current directory,
+ how should I change the Makefile. I have tried that obj:../foo.c, but the
+ foo.o will be in ../, not in the current directory.
+ <hacklu> As say, When I build gdbserver, I want to use [gdb]/gdb/gnu-nat.c,
+ How can I get the gnu-nat.o under gdbserver's directory?
+ <hacklu> tschwinge: ^^
+ <tschwinge> Hi!
+ <tschwinge> hacklu: Heh, unexpected problem.
+ <tschwinge> hacklu: How is this handled for the files that are already in
+ gdb/common/? I think these would have the very same problem?
+ <hacklu> tschwinge: ah.
+ <hacklu> I got it
+ <tschwinge> I see, for example:
+ <tschwinge> ./gdb/
+ ${srcdir}/common/linux-btrace.c
+ <tschwinge> ./gdb/gdbserver/
+ ../common/linux-btrace.c $(linux_btrace_h) $(server_h)
+ <hacklu> If I have asked before, I won't use soft link to solve this.
+ <tschwinge> But isn't that what you've been trying?
+ <hacklu> when this, where the .o file go to?
+ <tschwinge> Yes, symlinks can't be used, because they're not available on
+ every (file) system GDB can be built on.
+ <tschwinge> I would assume the .o files to go into the current working
+ directory.
+ <tschwinge> Wonder why this didn't work for you.
+ <hacklu> in gdbserver/configure.srv, there is a srv_tgtobj="gnu_nat.c ..",
+ if I change the, it doesn't gdb's way.
+ <hacklu> So I can't use the variable srv_tgtobj?
+ <tschwinge> That should be srv_tgtobj="gnu_nat.o [...]"? (Not .c.)
+ <hacklu> I have try this, srv_tgtobj="../gnu_nat.c", then the gnu_nat.o is
+ generate in the parent directory.
+ <hacklu> s/.c/.o
+ <hacklu> (wrong input)
+ <hacklu> For my understand now, I should set the srv_tgtobj="", and then
+ set the gnu_nat.o:../gnu_nat.c in the gdbserver/ right?
+ <tschwinge> Hmm, I thought you'd need both.
+ <tschwinge> Have you tried that?
+ <hacklu> no, haven't yet. I will try soon.
+ <hacklu> I have met an strange thing. I have this in Makefile,
+ i386gnu-nat.o:../i386gnu-nat.c $(CC) -c $(CPPFLAGS) $(INTERNAL_CFLAGS) $<
+ <hacklu> When make, it will complain that: no rules for target
+ i386gnu-nat.c
+ <hacklu> but I also have a line gnu-nat.o:../gnu-nat.c ../gnu-nat.h. this
+ works well.
+ <tschwinge> hacklu: Does it work if you use $(srcdir)/../i386gnu-nat.c
+ instead of ../i386gnu-nat.c?
+ <tschwinge> Or similar.
+ <hacklu> I have try this, i386gnu-nat.c: echo "" ; then it works.
+ <hacklu> (try $(srcdir) ing..)
+ <hacklu> make: *** No rule to make target `.../i386gnu-nat.c', needed by
+ `i386gnu-nat.o'. Stop.
+ <hacklu> seems no use.
+ <hacklu> tschwinge: I have found another thing, if I rename the
+ i386gnu-nat.o to other one, like i386gnu-nat2.o. It works!
+# IRC, freenode, #hurd, 2013-09-07
+ <hacklu> hi, I have found many '^L' in gnu-nat.c, should I fix it or keep
+ origin?
+ <LarstiQ> hacklu: fix in what sense?
+ <hacklu> remove the line contains ^L
+ <LarstiQ> hacklu: see bottom of
+ <LarstiQ> hacklu: "Please use formfeed characters (control-L) to divide the
+ program into pages at logical places (but not within a function)."
+ <LarstiQ> hacklu: so unless a reason has come up to deviate from the gnu
+ coding standards, those ^L's are there by design
+ <hacklu> LarstiQ: Thank you! I always think that are some format error. I
+ am stupid.
+ <LarstiQ> hacklu: not stupid, you just weren't aware
+ * LarstiQ thought the same when he first encountered them
+# IRC, freenode, #hurd, 2013-09-09
+ <youpi> hacklu_, hacklu__: I don't know what tschwinge thinks, but I guess
+ you should work with upstream on integration of your existing work, this
+ is part of the gsoc goal: submitting one's stuff to projects
+ <tschwinge> youpi: Which is what we're doing (see the patches recently
+ posted). :-)
+ <youpi> ok
+ <hacklu__> youpi: I always doing what you have suggest. :)
+ <hacklu> I have asked in my new mail, I want to ask at here again. Should
+ I change the gdb use lwp filed instead of tid field? There are
+ <hacklu> too many functions use tid. Like
+ <hacklu> named tid in the structure proc also.
+ <hacklu> make_proc(),inf_tid_to_thread(),ptid_build(), and there is a field
+ <hacklu> (sorry for the bad \n )
+ <hacklu> and this is my weekly
+ report.
+ <hacklu> And in Pedro Alves's reply, he want me to integration only one
+ back-end for gdb and gdbserver. but the struct target_obs are just
+ decalre different in both of the two. How can I integrate this? or I got
+ the mistaken understanding?
+ <hacklu> tschwinge: ^^
+ <tschwinge> hacklu: I will take this to email, so that Pedro et al. can
+ comment, too.
+ <tschwinge> hacklu: I'm not sure about your struct target_ops question.
+ Can you replay to Pedro's email to ask about this?
+ <hacklu> tschwinge: ok.
+ <tschwinge> hacklu: I have sent an email about the LWP/TID question.
+ <hacklu> tschwinge: Thanks for your email, now I know how to fix the
+ LWP/TID for this moment.
+ <tschwinge> hacklu: Let's hope that Pedro also is fine with this. :-)
+ <hacklu> tschwinge: BTW, I have a question, if we just use a locally
+ auto-generated number to distignuish threads in a process, How can we do
+ that?
+ <hacklu> How can we know which thread throwed the exception?
+ <hacklu> I haven't thought about this before.
+ <tschwinge> hacklu: make_proc sets up a mapping from Mach threads to GDB's
+ TIDs. And then, for example inf_tid_to_thread is used to look that up.
+ <hacklu> tschwinge: oh, yeah. that is.
+# IRC, freenode, #hurd, 2013-09-16
+ <tschwinge> hacklu: Even when waiting for Pedro (and me) to comment, I
+ guess you're not out of work, but can continue in parallel with other
+ things, or improve the patch?
+ <hacklu> tschwinge: honestly to say, these days I am out of work T_T after
+ I have update the patch.
+ <hacklu> I am not sure how to improve the patch beyond your comment in the
+ email. I have just run some testcase and nothing others.
+ <tschwinge> hacklu: I have not yet seen any report on the GDB testsuite
+ results using your gdbserver port (see
+ gdb/testsuite/boards/native-gdbserver.exp). :-D
+ <hacklu> question is, the resule of that testcase is just how many pass how
+ many not pass.
+ <hacklu> and I am not sure whether need to give this information.
+ <tschwinge> Just as a native run of GDB's testsuite, this will create *.sum
+ and *.log files, and these you can diff to those of a native run of GDB's
+ testsuite.
+ <hacklu> this is my result
+ === gdb Summary ===
+ # of expected passes 15573
+ # of unexpected failures 609
+ # of unexpected successes 1
+ # of expected failures 31
+ # of known failures 57
+ # of unresolved testcases 6
+ # of untested testcases 47
+ # of unsupported tests 189
+ /home/hacklu/code/gdb/gdb/testsuite/../../gdb/gdb version -nw -nx -data-directory /home/hacklu/code/gdb/gdb/testsuite/../data-directory
+ make[3]: *** [check-single] Error 1
+ make[3]: Leaving directory `/home/hacklu/code/gdb/gdb/testsuite'
+ make[2]: *** [check] Error 2
+ make[2]: Leaving directory `/home/hacklu/code/gdb/gdb'
+ make[1]: *** [check-gdb] Error 2
+ make[1]: Leaving directory `/home/hacklu/code/gdb'
+ make: *** [do-check] Error 2
+ <hacklu> I got a make error so I don't get the *.sum and *.log file.
+ <tschwinge> Well, that should be fixed then?
+ <tschwinge> hacklu: When does university start again for you?
+ <hacklu> My university have start a week ago.
+ <hacklu> but I will fix this,
+ <tschwinge> Oh, OK. So you won't have too much time anymore for GDB/Hurd
+ work?
+ <hacklu> it is my duty to finish my work.
+ <hacklu> time is not the main problem to me, I will shedule it for myself.
+ <tschwinge> hacklu: Thanks! Of course, we'd be very happy if you stay with
+ us, and continue working on this project (or another one)! :-D
+ <hacklu> I also thanks all of you who helped me and mentor me to improve
+ myself.
+ <hacklu> then, what the next I can do is that fix the testcase failed?
+ <tschwinge> hacklu: It's been our pleasure!
+ <tschwinge> hacklu: A comparison of the GDB testsuite results for a native
+ and gdbserver run would be good to get an understanding of the current
+ status.
+ <hacklu> ok, I will give this comparison soon. BTW,should I compare the
+ native gdb result with the one before my patch
+ <tschwinge> You mean compare the native run before and after your patch?
+ Yes, that also wouldn't hurt to do, to show that your patch doesn't
+ introduce any regressions to the native GDB port.
+ <hacklu> ok, beside this I should compare the native gdb with gdbserver ?
+ <tschwinge> Yes.
+ <hacklu> beside this, what I can do more?
+ <tschwinge> No doubt, there will be differences between the native and
+ gdbserver test runs -- the goal is to reduce these. (This will probably
+ translate to: implement more stuff for the Hurd port of gdbserver.)
+ <hacklu> ok, I know it. Start it now
+ <tschwinge> As time permits. :-)
+ <hacklu> It's ok. :)
+# IRC, freenode, #hurd, 2013-09-23
+ <hacklu_> I have to go out in a few miniutes, will be back at 8pm. I am
+ sorry to miss the meeting this week, I will finishi my report soon.
+ <hacklu_> tschwinge, youpi ^^
diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn
index 43f9b14c..a9176f51 100644
--- a/community/gsoc/2013/nlightnfotis.mdwn
+++ b/community/gsoc/2013/nlightnfotis.mdwn
@@ -448,3 +448,2590 @@ License|/fdl]]."]]"""]]
<tschwinge> nlightnfotis: OK, so probably waiting at the FSF office to be
processed. Let's allow for some more time. After all, this is not
critical for your progress.
+# IRC, freenode, #hurd, 2013-07-10
+ <nlightnfotis> tschwinge: I have run the diff of the GCC repo on the Hurd
+ against the one on my host linux os, and there was nothing relevant to
+ fixcontext and initcontext that are the ones that fail the
+ compilation. In any case I did recheck out the branch, and I have
+ attempted a build with it. It fails at the same point. Now I am
+ attempting a build with the -w (inhibit warnings) flag enabled
+ <tschwinge> nlightnfotis: Have there been any differences in the diff?
+ There should be none at all.
+ <nlightnfotis> tschwinge: there were some small changes due to the repo's
+ being checked out at different times. It was a large diff however. I
+ inspected it and didn't find anythign that was of much use. Here it is in
+ case you might want to see it:
+ <tschwinge> nlightnfotis: Well, the idea of this exercise precisely was to
+ use the same Git revisions on both sides of the diff -- to show that
+ there are no spurious differences -- which can't be shown from your
+ 124486 lines diff. (Even though indeed there is no difference in
+ libgo/configure that would explain the mis-match, but who knows what else
+ might be relevant for that.
+ <tschwinge> Would you please repeat that?
+ <nlightnfotis> tschwinge: I will do so. It was wrong from me to not diff
+ against the same revisions, but going through the diff results grepping
+ for the problematic code didn't yield any results, so I thought that
+ might not be the issue.
+ <nlightnfotis> I will perform the diff again tomorrow morning and report on
+ the results.
+ <tschwinge> nlightnfotis: Anyway, if you checked out again, the latest
+ revision, and it still fails in exactly the same way, there is something
+ wrong.
+ <tschwinge> nlightnfotis: And -w won't help, as there is a hard error
+ involved.
+ <tschwinge> nlightnfotis: Are yous till working on GSoC things today?
+ <nlightnfotis> tschwinge: yeah I am here. I decided to do the diff today
+ instead of tomorrow.
+ <nlightnfotis> It finished now btw
+ <nlightnfotis> let me tell you
+ <nlightnfotis> ah and this time, the gits were checked out at the same time
+ <nlightnfotis> from the same source
+ <nlightnfotis> and are at the same branch
+ <tschwinge> nlightnfotis: Coulod you upload the
+ gccbuild/i686-unknown-gnu0.3/libgo/config.log of the build that failed?
+ <nlightnfotis> tschwinge: sure. give me a minute
+ <nlightnfotis> tschwinge: there is something strange going on. The two
+ repos are at the exact same state (or at least should be, and the logs
+ indicate them to be) but still the diff output is 4.4 mb
+ <nlightnfotis> but no presence of initcontext of fixcontext
+ <nlightnfotis> tschwinge: the config.log file -->
+ <nlightnfotis> wow! I can see several errors in the config.log file
+ <nlightnfotis> but I am not so sure about their fatality. Config returns 0
+ at the end of the log
+ <tschwinge> nlightnfotis: As the configure scripts probe for all kings of
+ features on all kings of strange systems, it's to be expected that some
+ of these fail on GNU/Hurd.
+ <tschwinge> What is not expected, however, is:
+ <tschwinge> configure:15046: checking whether setcontext clobbers TLS
+ variables
+ <tschwinge> [...]
+ <tschwinge> configure:15172: ./conftest
+ <tschwinge> /root/gcc_new/gcc/libgo/configure: line 1740: 1015 Aborted
+ ./conftest$ac_exeext
+ <tschwinge> Hmm. apt-cache policy libc0.3
+ <tschwinge> nlightnfotis: ^
+ <nlightnfotis> tschwinge: Installed 2.13-39+hurd.3
+ <nlightnfotis> Candidate: 2.1-6
+ <nlightnfotis> *2.17
+ <tschwinge> Bummer.
+ <tschwinge> nlightnfotis: As indicated in
+ <>
+ and thereabouts, you need 2.17-3+hurd.4 or later...
+ <tschwinge> Well.
+ <tschwinge> At least that now explains what is going on.
+ <nlightnfotis> tschwinge: i see. I am in the process of updating my hurd
+ vm. I saw that libc has also been updated to 2.17
+ <nlightnfotis> I will confirm when updating is done
+ <tschwinge> nlightnfotis: Anyway, is the diff between the two repositories
+ empty now or are there still differences?
+ <nlightnfotis> there are differences
+ <nlightnfotis> and they were checked out at the same time
+ <nlightnfotis> from the same source
+ <nlightnfotis> (the official git mirror)
+ <nlightnfotis> and they are both at the same branch
+ <nlightnfotis> and still diff output is 4.4 MB
+ <nlightnfotis> but quick grepping into it and there is not mention of
+ initcontext or fixcontext
+ <tschwinge> That's... unexpected.
+ <nlightnfotis> may be a mistake I am making
+ <nlightnfotis> but considering that diff run for some time before
+ completing
+ <tschwinge> In both Git repositories, »git rev-parse HEAD« shows the same
+ thing?
+ <tschwinge> Could you please upload the diff again?
+ <nlightnfotis> tschwinge: confirmed. libc is now version 2.17-1
+ <nlightnfotis> tschwinge:
+ <nlightnfotis> for the rev-parse give me a second
+ <tschwinge> nlightnfotis: Where is libc0.3 2.17-1 coming from? You need
+ 2.17-3+hurd.4 or later.
+ <nlightnfotis> it is 2.17-7+hurd.1
+ <tschwinge> OK, good.
+ <tschwinge> The URL you just have is the config.log file, not the diff.
+ <tschwinge> s%have%gave
+ <nlightnfotis> oh my mistake
+ <nlightnfotis> wait a minute
+ <nlightnfotis> the two repos have different output to rev-parse
+ <tschwinge> Phew.
+ <tschwinge> That explains.
+ <tschwinge> So the Git branches are at different revisions.
+ <nlightnfotis> that confused me... when I run git pull -a the branches that
+ were changed were all updated to the same revision
+ <nlightnfotis> unless... there were some automatic merges in the *host* GCC
+ repo required during some pulls
+ <nlightnfotis> but that was some time ago
+ <nlightnfotis> would it have messed my local history that much?
+ <nlightnfotis> that's the only thing that may be different between the two
+ repos
+ <nlightnfotis> they checkout from the same source
+ <tschwinge> nlightnfotis: At which revisions are the two
+ repositories/branches?
+ <tschwinge> I have never used »put pull -a«. What does that do?
+ <nlightnfotis> tschwinge: from what I know it does an automatic git fetch
+ followed by git merge. The -a flag must signal to pull all branches (I
+ think it's possible to pull only one branch)
+ <tschwinge> That's the --all option. -a is something different (that I
+ don't understand off-hand).
+ <tschwinge> Well, --all means to pull all remotes.
+ <tschwinge> But you just want the GCC upstream, I guess.
+ <tschwinge> I always use git fetch and git merge manually.
+ <nlightnfotis> oh my god! You are write. -a is equivallent to --append
+ <nlightnfotis>
+ <nlightnfotis> git pull must be safe though
+ <nlightnfotis>
+ <nlightnfotis> without the -a
+ <nlightnfotis> *right
+ <nlightnfotis> why did I even write "right" as "write" above I don't
+ even...
+ <nlightnfotis> what did I write in the sentence above
+ <nlightnfotis> oh my god...
+ <nlightnfotis> tschwinge: they are indeed on different revisions: The host
+ repo's last commit was made by me apparently, to merge master into
+ tschwinge/t/hurd/go, whereas the last commit of the Hurd repo was by you
+ and it reverted commit 2eb51ea
+ <nlightnfotis> and that should also explain the large diff file
+ <nlightnfotis> with master merged into the tschwinge/t/hurd/go branch
+ <nlightnfotis> I will purge the debian repo and redownload it
+ <nlightnfotis> *reclone it
+ <nlightnfotis> that should bring it to a safe state I suppose.
+# IRC, freenode, #hurd, 2013-07-11
+ <teythoon> nlightnfotis: how's your build going?
+ <nlightnfotis> I tried one earlier and it seemed to build without any
+ issues, something that was...strange. I am repeating the build now, but I
+ am saving the compilation output this time to study it.
+ <teythoon> it was strange that the build succeeded? that sounds sad :/
+ <nlightnfotis> teythoon: considering that 3 weeks now I failed to build it
+ without errors, it sure seems weird that it builds without errors now :)
+ <braunr> what did you change ?
+ <nlightnfotis> braunr: not many things apparently. To be honest the change
+ that seemed to do the trick was (under thomas' guidance) update of libc
+ from 2.13 to 2.17
+ <braunr> well that can explain
+ <nlightnfotis> tschwinge: Big update! GCC-go not compiles without errors
+ under the Hurd. I have done 2 compilations so far, none of which had
+ issues. Time needed for full build (without bootstrap) is 45 minutes +- 1
+ minute. I also run the test suite, and I can confirm your results
+ <pinotree> s/not/now/, perhaps?
+ <nlightnfotis> pinotree yeah. I don't know how it came up with not there. I
+ meant now
+ <nlightnfotis> tschwinge: link for the go.sum is here -->
+# IRC, freenode, #hurd, 2013-07-12
+ <tschwinge> nlightnfotis: Great! So you finally reproduced my results.
+ :-)
+ <nlightnfotis> tschwinge: Yep! I am now building a blog, so that I can move
+ my reports there, so that they are more detailed, to allow for greater
+ transparency of my actions
+ <tschwinge> nlightnfotis: Did you recently (in email, I think?) indicate
+ that there is another Go testsuite, for libgo?
+ <tschwinge> nlightnfotis: As you prefer.
+ <nlightnfotis> tschwinge: there seemed to be one, at least in linux. I
+ think I saw one in the Hurd too.
+ <tschwinge> Oh indeed there is a libgo testsuite, too.
+ <nlightnfotis> as a matter of fact, make check-go
+ <nlightnfotis> did check for the lib
+ <nlightnfotis> but lib was failing
+ <nlightnfotis> yeah
+ <tschwinge> So please have a look at that testsuite's results, too, and
+ compare to the GNU/Linux ones.
+ <nlightnfotis> sure. I can do that now.
+ <tschwinge> And for the go.sum you posted, please have a look at the tests
+ that do not pass (»grep -v ^PASS: < go.sum«), assuming they do pass on
+ GNU/Linux.
+ <tschwinge> I suggest you add a list of the differences between GNU/Linux
+ and GNU/Hurd testresults to the wiki page,
+ <>, at the end of
+ the Part I section.
+ <nlightnfotis> I'm on it.
+ <tschwinge> For now, please ignore any failing tests that have »select« in
+ their name -- that is, do file them, but do not spend a lot of time
+ figuring out what might be wrong there.
+ <tschwinge> The Hurd's select implementation is a bit of a beast, and I
+ don't want you -- at this time -- spend a lot of time on that. We
+ already know there are some deficiencies, so we should postpone that to
+ later.
+ <nlightnfotis> tschwinge: noted.
+ <tschwinge> So what I would like at the moment, is a list of the testresult
+ differences to GNU/Linux, then from the go.log file any useful
+ information about the failing test (which perhaps already explains)
+ what's going wrong, and then a analysis of the failure.
+ <tschwinge> nlightnfotis: I assume you must be really happy that you
+ finally got it build fine, and reproduced my results. :-)
+ <nlightnfotis> tschwinge: yeah! I can not hide from you the fact that
+ failing all those builds made me really nervous about me missing my
+ schedule. Having finally built that and revisiting my application I can
+ see I am on schedule, but I have to intensify my work to compensate for
+ any potential unforeseen obstacles
+ <nlightnfotis> , in the futute
+ <nlightnfotis> *future
+# IRC, freenode, #hurd, 2013-07-15
+ <youpi> nlightnfotis: btw, do you have a weekly progress report?
+ <nlightnfotis> youpi: not yet. Will write it shortly and post it here. I
+ made a new blog to keep track of my progress.
+ <nlightnfotis> Will report much more frequently now via my blog
+ <youpi> did you add your blog url to the hurd iwki?
+ <nlightnfotis> currently I am running gcc tests on both gcc go and libgo to
+ see what the differences are with Linux
+ <nlightnfotis> I believe I have done so, let me see
+ <nlightnfotis> youpi: gccgo passes most of its tests (it fails a small
+ number, and I am looking into those tests) but libgo fails 130/131 tests
+ (on the Hurd that is)
+ <youpi> ok
+ <nlightnfotis> guys I wrote my report. This time I made it available on my
+ personal blog. You can find it here:
+ As always,
+ open to (and encouraging) criticism, suggestions, anything that might
+ help me.
+ <nlightnfotis> I also have to mention that now that my personal website is
+ online, I will report much more frequently, to the scale of reporting day
+ by day, or every 2-3 days.
+ <youpi> nlightnfotis: without spending time on select, it'd be good to have
+ an idea of what is going wrong
+ <braunr> eh, go having trouble with select
+ <youpi> select is a beast, but we do have fixed things lately and we don't
+ currently know any issue still pending
+ <nlightnfotis> youpi: are you suggesting to not skip the select tests too?
+ <braunr> select is kind of critical ..
+ <braunr> as youpi said, if you can determine what's wrong, at the interface
+ level (not the implementation), it would be a good thing to do
+ <youpi> so we know what's wrong
+ <youpi> we're not asking to fix it, though
+ <nlightnfotis> braunr: youpi: noted. Thanks for the feedback. Is there
+ something else you might want me to improve? Something with the report
+ itself? Something you were expecting to see but I failed to provide?
+ <braunr> no it's ok
+ <braunr> it's short, readable, and readily answers the questions i might
+ have had so it's good
+ <braunr> as you say, now you have to work on the core of your task :)
+ <youpi> note: the "select" word in the testsuite is not strictly bound to
+ the C "select"
+ <youpi> so it is probably really worth digging a bit at least on the go
+ side
+ <braunr> but it's really worth doing in the end, as it will probably reveal
+ some nasty bugs on the way
+ <nlightnfotis> I appreciate your input. I will start working on it asap
+ (today) and will report on Wednesday perhaps (or Thursday at worst).
+# IRC, freenode, #hurd, 2013-07-18
+ <nlightnfotis> braunr: I found out what was causing the fails in the tests
+ <nlightnfotis> in both libgo and gccgo
+ <nlightnfotis> it's a assertion: mach_port_t ktid = __mach_thread_self ();
+ int ok = thread->kernel_thread == ktid; __mach_port_deallocate
+ ((__mach_task_self_ + 0), ktid); ok; })
+ <braunr> is all that the assertion ?
+ <nlightnfotis> yes
+ <braunr> please paste the code somewhere
+ <braunr> or is it in libpthread ?
+ <nlightnfotis>
+ nonblock.x: ./pthread/pt-create.c:167: __pthread_create_internal: Assertion `({ mach_port_t ktid = __mach_thread_self (); int ok = thread->kernel_thread == ktid; __mach_port_deallocate ((__mach_task_self_ + 0), ktid); ok; })' failed.
+ 9 FAIL: go.test/test/chan/nonblock.go execution, -O2 -g
+ <braunr> yes
+ <braunr> that's related to my current work on thread destruction
+ <braunr> thread resources recycling is buggy
+ <braunr> i suggest you make your own thread pool if you can
+ <nlightnfotis> I will look into it further and let you know. Thanks for
+ that.
+# IRC, freenode, #hurd, 2013-07-22
+ <nlightnfotis> tschwinge, I have found what is failing both libgo and gccgo
+ tests, but for the life of me, I can not really find the offending code
+ on any repository.
+ <nlightnfotis> not even the eglibc-source debian package. it's driving me
+ insane.
+ <tschwinge> nlightnfotis: If this is driving you insane, we should quickly
+ have a look at that!
+ <nlightnfotis> thanks tschwinge: I have found that the offending code is an
+ assertion: { mach_port_t ktid = __mach_thread_self (); int ok =
+ thread->kernel_th read == ktid; __mach_port_deallocate ((__mach_task_s
+ elf_ + 0), ktid); ok; } on a file called pt-create.c under the
+ libpthread on line 167
+ <nlightnfotis> but for the life of me, I can not find that piece of code
+ anywhere. And when I mean anywhere, I mean anywhere. I have looked for it
+ on all of the branches of glibc, libpthread and the source code of
+ eglibc.
+ <nlightnfotis> that's why if you don't mind I would like to write my report
+ in a day or two, when (hopefully) I will have more progress to report on.
+ <youpi> nlightnfotis: isn't that libpthread/sysdeps/mach/pt-thread-start.c
+ ?
+ <youpi> or rather, ./sysdeps/mach/hurd/pt-sysdep.h
+ <nlightnfotis> youpi: let me check this out. If that's it I'm gonna cry.
+ <youpi> which unfortunately is inlined in a lot of places
+ <youpi> nlightnfotis: does the assertion not tell you the file & line?
+ <nlightnfotis> youpi: holy smokes! That's the code I was looking for! Oh
+ boy. Yeah the logs do tell me, but it was very misleading. So misleading,
+ taht I was actually looking at the wrong place. All logs suggest that
+ this piece of code is at libpthread/pthread/pt-create.c in line 167
+ <youpi> what is that line in your tree?
+ <youpi> a call to _pthread_self(), isn't it?
+ <youpi> then it's not actually misleading, this is indeed where the
+ pt-sysdep.h definition gets inlined
+ <nlightnfotis> it seems so, yeah. it's err = __pthread_sigstate
+ (_pthread_self (), 0, 0, &sigset, 0);
+ <youpi> nlightnfotis: and what is the backtrace?
+ <nlightnfotis> youpi: _pthread_create_internal: Assertion failed.
+ <nlightnfotis> The assertion is the one above
+ <youpi> nlightnfotis: sure, but what is the backtrace?
+ <nlightnfotis> I don't have the full backtrace. These are the logs from the
+ compiler. All I can get is: reports like this: nonblock.x:
+ ./pthread/pt-create.c:167: __pthread_create_internal: Assertion `({
+ mach_port_t ktid = __mach_thread_self (); int ok = thread->kernel_thread
+ == ktid; __mach_port_deallocate ((__mach_task_self_ + 0), ktid);
+ ok; })' failed.
+ <youpi> nlightnfotis: you should probably have a look at running the tests
+ by hand
+ <youpi> so you can run them in a debugger, and get backtraces etc.
+ <braunr> nlightnfotis: did i answer that ?
+ <nlightnfotis> braunr: which one?
+ <braunr> the problems you're seeing are the pthread resources leaks i've
+ been trying to fix lately
+ <braunr> they're not only leaks
+ <braunr> creation and destruction are buggy
+ <nlightnfotis> I have read so in
+ I believe it's under
+ Thread's Death right?
+ <braunr> nlightnfotis: yes but it's buggy
+ <braunr> and the description doesn't describe the bugs
+ <nlightnfotis> so we will either have to find a temporary workaround, or
+ better yet work on a fix, right?
+ <braunr> nlightnfotis: i also told you the work around
+ <braunr> nlightnfotis: create a thread pool
+ <nlightnfotis> braunr: since thread creation is also buggy, wouldn't the
+ thread pool be buggy too?
+ <braunr> nlightnfotis: creation *and* destruction is buggy
+ <braunr> nlightnfotis: i.e. recycling is buggy
+ <braunr> nlightnfotis: the hurd servers aren't affected much because the
+ worker threads are actually never destroyed on debian (because of a
+ debian specific patch)
+ <teythoon> youpi, nlightnfotis, hacklu_: btw, what about the copyright
+ assignment process
+ <tschwinge> nlightnfotis just got his on file, so there is progress.
+ <tschwinge> I have email from Donald R Robertson III
+ <> about that -- but it is not yet present in the
+ FSF copyright.list file...
+ <tschwinge> I think I received that email because I was CCed on
+ nlightnfotis' submission.
+ <nlightnfotis> tschwinge: I have got the papers, and they were signed by
+ the FSF. They stated delivery date 11 of July, but the documents were
+ signed on the 10th of July :P
+ <tschwinge> Ah, no, I received it via -- and the
+ strange thing is that not all assignments that got processed got sent
+ there...
+ <tschwinge> At the recent GNU Tools Cauldron we also discussed this in the
+ GCC context; and their experience was the very same. Emails get lost,
+ and/or take ages to be processed, etc.
+ <tschwinge> It seems the FSF is undermanned.
+# IRC, freenode, #hurd, 2013-07-27
+ <nlightnfotis> I have one question about the Mach sources: I can see it
+ uses its own scheduler (more like, initializes) and also does the same
+ for the linux scheduler. Which one does it use?
+ <youpi> it doesn't use the linux scheduler
+ <youpi> the linux glue just glues linux scheduling concepts onto the mach
+ scheduler
+ <nlightnfotis> ohh I see now. Thanks for that youpi.
+# IRC, freenode, #hurd, 2013-07-28
+ <nlightnfotis> In the mach kernel source code, does the (void) before a
+ function call have a semantic meaning, or is it just remnants of the past
+ (or even documentation)
+ <pinotree> for example?
+ <nlightnfotis> pinotree: (void) thread_create (kernel_task,
+ &startup_thread);
+ <nlightnfotis> I read on stack overflow that there is only one case where
+ it has a semantic meaning, most of the times it doesn't
+ <nlightnfotis>
+ <pinotree> most probably thread_create has a non-void return value, and
+ this way you're explicitly suppressing its return value (usually because
+ you don't want/need to care about it)
+ <nlightnfotis> isn't the value discarded if the (void) is not there?
+ <pinotree> yes, but depending on extra attributes and/or compiler warning
+ flags the compiler might warn that the return value is not used while it
+ ought to
+ <pinotree> the cast to void should suppress that
+ <nlightnfotis> oh, okay, thanks for that pinotree
+ <nlightnfotis> and yes you are right that thread_create actually does
+ return something
+ <pinotree> even if there would be no compiler message about that, adding
+ the explicit cast could mean "yes, i know the function does return
+ something, but i don't care about it"
+ <pinotree> ... as hint to other code readers
+ <nlightnfotis> as a form of documentation then
+ <pinotree> also
+ <nlightnfotis> oh well, I am gonna ask and I hope someone will answer it:
+ In the Mach's dmesg (/var/log/dmesg) I can see that the version string
+ along with initial memory mapping information are printed twice, when in
+ fact they are supposed to be called only once. Is this a bug, or some
+ buffering error, or are they actually called twice for some reason?
+# IRC, freenode, #hurd, 2013-07-29
+ <nlightnfotis> guys is the evaluation today?
+ <hacklu_> yes
+ <teythoon> right
+ <nlightnfotis> where can we find the evaluation papers on melange?
+ <hacklu_> wait untill 12pm UTC.
+ <nlightnfotis> yeah, I just noticed thanks hacklu_
+ <hacklu_> nlightnfotis:)
+ <NlightNFotis> tschwinge: I only have one question regarding my project. If
+ I make some changes to libpthread, what's the best way to test them in
+ the hurd? Rebuild glibc with the updated libpthread?
+ <tschwinge> NlightNFotis: Yes, you'll have to rebuild glibc. I have a
+ cheat sheet for that:
+ <tschwinge> It may be that the »Run debian/rules patch to apply patches«
+ step is no longer encessary with the 2.17 glibc packages.
+ <NlightNFotis> thanks for that tschwinge. :)
+ <tschwinge> NlightNFotis: Sure. :-)
+ <tschwinge> NlightNFotis: Where's your weekly status?
+ <NlightNFotis> I will write it today at the noon. I have written all the
+ other ones, and they are available at
+ <NlightNFotis> the next one will be available there as well, later in the
+ day
+ <tschwinge> Ack. But please try to finish your report before the meeting,
+ as discussed.
+ <NlightNFotis> oh, forgive me for that. I thought it was ok to write my
+ report a day or so later. Sorry.
+ <tschwinge> NlightNFotis: Please write your report as soon as possible --
+ otherwise there's no useful way for me to know what your status is.
+ <NlightNFotis> I will. This week I have been mostly going through the
+ various sources (the Hurd, Mach and libpthread, especially the last two)
+ in my attempt to get a better understanding for how libpthread
+ works. Since yesterday I have attempted some small changes on my
+ libpthread repo that I plan on testing and reporting on them. That's why
+ I still have not written my report.
+ <tschwinge> NlightNFotis: Things don't need to be finished before you
+ report about them. It's often more useful to discuss issues *before* you
+ spend time on implementing them.
+ #hurd
+ <braunr> NlightNFotis: what kind of changes do you want to add to
+ libpthread ?
+ <tschwinge> Have a look at the asseriton failure, I would hope. :-)
+ <braunr> well no
+ <braunr> again, i did that
+ <braunr> and it's not easy to fix
+ <NlightNFotis> braunr: I was looking into ways that I could create the
+ thread pool you suggested into libpthread
+ <braunr> no, don't
+ <braunr> create it in your application
+ <braunr> not in libpthread
+ <braunr> well, this may not be an acceptable solution either ..
+ <tschwinge> Before doing that we have to understand what exactly the Go
+ runtime is doing. It may just be a weird itneraction with the setcontext
+ et al. functions that I failed to think about when implementing these?
+ <NlightNFotis> the other possibility is the go runtime libraries. But I
+ thought that libpthread might be a better idea, since you told me that
+ creation *and* destruction are buggy
+ <hacklu> braunr: you are right, the signal thread is always exist. I have
+ got a wrong understand before.
+ <NlightNFotis> tschwinge: I can look into that, now. I will also include
+ that in my report.
+ <braunr> NlightNFotis: i don't see how this is a relevant argument ..
+ <braunr> tschwinge: i'd suggest he first try with a custom pool in the go
+ runtime, so we exclude what you're suspecting
+ <braunr> if this pool actually works around the issues NlightNFotis is
+ having, it will confirm the offending problem comes from libpthread
+ <tschwinge> So, as a very first step make any thread
+ distruction/deallocation a no-op.
+ <braunr> yes
+ <NlightNFotis> braunr: I originally understood that a thread pool might
+ skip the thread's destruction, so that we escape the buggy part with the
+ thread's destruction. Since that was a problem with libpthread, it sure
+ affects other threads (instead of go's ) too. So I assumed that building
+ the thread pool into libpthread might help eliminate bugs that may affect
+ other code too.
+ <braunr> no, it's not a proper fix
+ <braunr> it's a work around
+ <braunr> and i'm working on a proper fix in parallel
+ <braunr> (when i have the time, that is :/)
+ <NlightNFotis> oh, I see. So for the time, I had better not touch
+ libpthread, and take a look at the go run time aye?
+ <tschwinge> NlightNFotis: Remember: one thing after the other. First
+ identify what is wrong exactly. Then think and discuss how to solve the
+ very specific issue. Then implement it.
+ <braunr> as tschwinge said, make thread destruction a nop in go
+ <braunr> see if that helps
+ <tschwinge> NlightNFotis: For example, you surely have noticed (per your
+ last report), that basically all Go language test pass (aside from the
+ handful of those testing select, etc.) -- but all those of the libgo
+ runtime library fail, literally all of them.
+ <tschwinge> You noticed they basically all fail with the same assertion
+ failure. But why do all the Go language ones work fine?
+ <tschwinge> Don't they execute the program they built, for example?
+ <tschwinge> (I haven't looked.)
+ <NlightNFotis> they do execute the program. the language ones that fail
+ too, fail due to the assertion failure
+ <tschwinge> Or, what else is different for them? How are they built, which
+ flags, how are they invoked.
+ <braunr> how many goroutines ?
+ <braunr> :p
+ <tschwinge> Do you also get the assertion failure when you built a small Go
+ program yourself and run that one.
+ <tschwinge> Don't get the assertion failure? Then add some more complex
+ stuff that are likely to invole adding/re-using new threads, such as
+ goroutines.
+ <NlightNFotis> I didn't get the assertion failure on a small test program,
+ but now that you suggest it it might be a good idea to build a custom
+ test suite
+ <tschwinge> Etc. That way you'll eventually get an understanding what
+ triggers the assertion failure.
+ <tschwinge> And that exeactly is the kind of analysis I'd like to read in
+ your weekly report.
+ <tschwinge> A list of things what you have done, which assuptions you've
+ made, how that directed your further analysis, what results that gave,
+ etc.
+ <NlightNFotis> I will do it. I will try to rush to finish it today before
+ you leave, so that you can inspect it. God I feel like all that time I
+ spent this week studying the particular source code (libpthread, and the
+ Mach) were in vain...
+ <NlightNFotis> on second thoughts, it was not in vain. I got a pretty good
+ understanding of how these pieces of software work, but now I will have
+ to do something completely different.
+ <tschwinge> Studying code is never in vain.
+ <tschwinge> Exactly.
+ <tschwinge> You must have had some motivation to study the code, so that
+ was surely a valid thing to do.
+ <tschwinge> But we'd link to understand your reasoning, so that we can
+ support you and direct you accordingly.
+ <braunr> but it's better to focus on your goals and determine an
+ appropriate course of actions, usually starting with good analysis
+ <tschwinge> Yes.
+ <pinotree> s/link/like/?
+ <tschwinge> pinotree: Indeed, thanks.
+ <braunr> makes me remember when i implemented radix trees to replace splay
+ trees, only to realize splay trees were barely used ..
+ <tschwinge> braunr: Yes. It has happened to all of us. ;-P
+ <tschwinge> NlightNFotis: So, don't worry -- but learn from such things.
+ :-)
+ <NlightNFotis> anyway, I will start right away with the courses of action
+ you suggested, and will try to have finished them by noon. Thanks for
+ your help, it really means a lot.
+ <tschwinge> In software generally, it is never a good idea to let you be
+ distracted, and don't follow your focus goal, because there are always so
+ many different things that could be improved/learned/fixed/etc.
+ <NlightNFotis> tschwinge, I am only nervous about one thing: the fact that
+ I have not submitted yet any patch or some piece of code in general. Then
+ again, the summer of code for me so far has been 70-80% reading about
+ stuff I didn't know about and 30-20% doing the stuff I should know
+ about...
+ <tschwinge> NlightNFotis: That's why we're here, to teach you something.
+ Which we're happy to do, but we all need to cooperate for that (and I'm
+ well aware that this is difficult if one is not in the same rooms, and
+ I'm also aware that my time is pretty limited).
+ <tschwinge> NlightNFotis: We're also very aware that the Hurd system, as
+ any operating system project (if you're not just doing "superficial"
+ things) is difficult, and takes lots of time to learn, and have concepts
+ and things sink into your brain.
+ <braunr> i wouldn't worry too much
+ <tschwinge> We're also still learning every day.
+ <braunr> go doesn't require a lot from the underlying system, but what is
+ required is critical
+ <braunr> once you identify it, coding will be quick
+ <NlightNFotis> tschwinge: braunr: thanks. I shall begin working following
+ the directions you gave to me.
+ <tschwinge> NlightNFotis: So yes, because Google wants us to grade you
+ based on that, you'll eventually have to write some code, but for
+ example, a patch to disable thread distruction/deallocation in libgo
+ would definitely count as such code. And that seems like one of your
+ next steps.
+ <NlightNFotis> tschwinge: i need to deliver that instantly, right? seeing
+ as the evaluation is today.
+ <tschwinge> NlightNFotis: No. Deliver it when you have something to
+ deliver. :-)
+ <NlightNFotis> tschwinge: I am nervous about the evaluation today. I have
+ not submitted a single piece of code, only some reports. How negatively
+ does this influence my performance report?
+ <tschwinge> NlightNFotis: If I can say so, in the evaluation today, Google
+ basically asks us mentors whether we want to fail our students right now.
+ Which I don'T plan to do, knowing about the complexity of the Hurd
+ system, and the learning required before you can do useful code changes.
+ <NlightNFotis> tschwinge: that really means a lot to me, and it got a
+ weight of my chest.
+ <braunr> uh ok, i have to be the rude guy again
+ <braunr> NlightNFotis: the gsoc is also a way for the student to prepare
+ for working in software development communities
+ <braunr> whether free software/open source and/or in companies
+ <braunr> people involved care a lot less about pathos than actual results
+ <pinotree> (or to prepare students to be hired by google, but that's
+ another story)
+ <braunr> NlightNFotis: in other words, stop apologizing that much, stop
+ focusing so much on that, and just work as you can
+# IRC, freenode, #hurd, 2013-07-31
+ <nlightnfotis> teythoon: both samuel and thomas would be missing for the
+ week right?
+ <teythoon> nlightnfotis: they do, why?
+ <teythoon> nlightnfotis: err, they do?? why?
+# IRC, freenode, #hurd, 2013-08-01
+ <nlightnfotis> braunr: I checked out what you (and Thomas) suggested and
+ did some research on go on the Hurd. I have found out that go works,
+ until you need to use anything that has to do with a goroutine. I am now
+ playing with the go runtime and checking to see if turning thread
+ destruction to noop will have any difference.
+# IRC, freenode, #hurd, 2013-08-05
+ <nlightnfotis> youpi: whenever you have time, I would like to report my
+ progress as well.
+ <youpi> nlightnfotis: sure, go ahead
+ <youpi> but again, you should report before the meeting
+ <youpi> so we can read it before coming to the discussion
+ <nlightnfotis> I have written my report
+ <youpi> ah
+ <hacklu> nlightnfotis: I have read your report, these days you have make a
+ great progress.
+ <youpi> where is it?
+ <nlightnfotis> it was available since yesterday
+ <nlightnfotis>
+ <nlightnfotis> thanks hacklu. The particular piece of code I was studying
+ was very very interesting :)
+ <hacklu> nlightnfotis: I think you should show your link in here or email
+ next time. I have spend a bit more time to find that :)
+ <nlightnfotis> youpi: for a tldr, at the last time I was told to check
+ gccgo's runtime for clues regarding the go routine failures.
+ <nlightnfotis> hacklu: will keep that in mind, thanks.
+ <nlightnfotis> youpi: thing is, gccgo operates on two different thread
+ types: G's (the goroutines, lightweight threads that are managed by the
+ runtime) and M's (the "real" kernel threads")
+ <nlightnfotis> none of which are really "destroyed"
+ <youpi> ok, makes sense
+ <nlightnfotis> G's are put in a pool of available goroutines when their
+ status is changed to "Gdead" so that they can be reused
+ <nlightnfotis> M's also don't seem to go away. There is always at least one
+ M (the bootstrap one) and all other M's that get created are also stashed
+ in a pool of available working threads.
+ <youpi> you could put some debugging printfs in libpthread, to make sure
+ whether threads do die or not
+ <nlightnfotis> I am studying this further as we speak, but they both don't
+ seem to get "destroyed", so that we can be sure that bugs are triggered
+ by thread destruction
+ <nlightnfotis> I was beginning to believe that maybe I was looking in the
+ wrong direction
+ <nlightnfotis> but then I looked at my past findings, and I noticed
+ something else
+ <nlightnfotis> if you take a look at the first failed go routine, it failed
+ at the time.sleep function, which puts a goroutine to sleep for ns
+ nanoseconds. That made me think if it was something that had to do with
+ the context functions and not the goroutines' creation.
+ <youpi> nlightnfotis: that's possible
+ <youpi> nlightnfotis: I'd say you can focus on this very simple example: a
+ mere sleep
+ <youpi> that's one of the simplest things a thread scheduler has to do, but
+ it has to do it right
+ <youpi> fixing that should fix a lot of other issues
+ <nlightnfotis> if I have understood correctly, there is at least one G
+ (Goroutine) and at least one M (kernel thread) running. Sleep does put
+ that goroutine at a hold, and restarting it might be an issue
+ <braunr> talking about thread scheduling ? :)
+ <youpi> nlightnfotis: go's runtime doesn't actually destroy kernel threads,
+ apparently
+ <nlightnfotis> youpi: yeah, that's what I have understood so far. And it
+ neither does destroy goroutines. If there was an issue with thread
+ creation, then I guess it should be triggered in the beginning of the
+ program too (seeing as both M's and G's are created there)
+ <nlightnfotis> the fact that it is triggered when a goroutine goes to sleep
+ makes me suspect the context functions
+ <youpi> yes
+ <nlightnfotis> again I am studying it the last days, in search of
+ clues. Will keep you all updated.
+ <nlightnfotis> braunr: I have written my report and it is available here
+ If you could read it and tell me if you notice something weird tell me
+ so.
+ <braunr> nlightnfotis: ok
+ <braunr> nlightnfotis: quite busy here so don't worry if i suddenly
+ disappear
+ <braunr> nlightnfotis: hum, does go implement its own threads ??
+ <nlightnfotis> braunr: yeah. It has 2 threads. Runtime managed (the
+ goroutines) and "real" (kernel managed) ones.
+ <braunr> i mean, does it still use libpthread ?
+ <nlightnfotis> thing is none of them "disappear" so as to explain the bug
+ with "thread creation **and** destruction)
+ <nlightnfotis> it must use libpthread for kernel threads as far as creation
+ goes.
+ <braunr> ok, good
+ <braunr> then, it schedules its own threads inside one pthread, right ?
+ <braunr> using the pthread as a virtual cpu
+ <nlightnfotis> yes. It matches kernel threads and runtime threads and runs
+ the kernel threads in reality
+ <nlightnfotis> the scheduler decides which goroutine will run on each
+ kernel thread.
+ <braunr> ew
+ <braunr> this is pretty much non portable
+ <braunr> and you're right to suspect context switching functions
+ <nlightnfotis> yeah my thought for it was the following: thread creation,
+ if it was buggy, should be triggered as soon as a program starts, seeing
+ as at least one kernel thread and at least one go routine starts. My
+ sleep experiment crashes when the goroutine is put on hold
+ <braunr> did you find the code putting on hold ?
+ <nlightnfotis> I will give you the exact link, wait a moment
+ <nlightnfotis> braunr:
+ <nlightnfotis> that is the exact location is line 26, which calls the one I
+ pointed you at
+ <braunr> ahah, tsleep
+ <braunr> old ghost from the past
+ <braunr> nlightnfotis: the real location is probably runtime_park
+ <nlightnfotis> I will check this out.
+ <nlightnfotis> may I ask something non-technical but relevant to summer of
+ code?
+ <braunr> sure
+ <nlightnfotis> would it be okay if I took the day off tomorrow?
+ <braunr> nlightnfotis: ask tschwinge but i guess it's ok
+ <braunr> have you found runtime_park ?
+ <braunr> i'm downloading your repository from github but it's slow :/
+ <nlightnfotis> braunr: not yet. Grepping through the files didn't produce
+ any meaningful results and github's search is not working
+ <nlightnfotis> braunr: there is that strange thing with th gccgo sources,
+ where I can find a function's declaration but not it's definition. Funny
+ thing is those functions are not really extern, so I am playing a hide
+ and seek game, in which I am not always successful.
+ <nlightnfotis> runtime_park is declared in runtime.h. I have looked nearly
+ everywhere for it. There is only one last place I have not looked at.
+ <nlightnfotis> braunr: I found runtime_park. It's here:
+ <tschwinge> nlightnfotis: Taking the day off is fine. Have fun!
+ <nlightnfotis> tschwinge: I am still here; Thanks for that tschwinge. I
+ will be for the next half hour or something if you would like to ask me
+ anything
+ <tschwinge> nlightnfotis: I have no immediate questions (first have to read
+ your report and discussion in here) -- so feel free to log out and enjoy
+ the sun outside. :-)
+ <teythoon> nlightnfotis, tschwinge: btw, have you seen
+ ?
+ <nlightnfotis> teythoon: thanks for the link. It's really interesting.
+# IRC, freenode, #hurd, 2013-08-12
+ <nlightnfotis> teythoon did you manage to build the Hurd successfuly?
+ <teythoon> ah yes, the Hurd is relatively easy
+ <teythoon> the libc is hard
+ <nlightnfotis> debian glibc or hurd upstream libc?
+ <teythoon> but my build on darnassus was successful
+ <nlightnfotis> *debian eglibc
+ <teythoon> well, I rebuilt the debian package with two tweaks
+ <nlightnfotis> do you build on linux and rsync on hurd or ...?
+ <teythoon> I built it on Hurd, though I thought about setting up a cross
+ compiler
+ <nlightnfotis> I see. The process was build Mach, build Hurd, and then
+ build glibc and it's ready or it needed more?
+ <teythoon> no, I never built Mach
+ <teythoon> I must admit I'm not sure about the "proper" procedure
+ <teythoon> if I change one of Hurds RPC definitions, I think the proper way
+ is to rebuild the libc against the new definitions and then the Hurd
+ <teythoon> but I found no way to do that, so everyone seems to build the
+ Hurd, install it, build the libc and then rebuild the Hurd again
+ <nlightnfotis> I see. Thanks for that :)
+ <nlightnfotis> tschwinge, I have also written my report! It's available
+ here
+ <nlightnfotis> I can sum it up if you want me to.
+ <tschwinge> nlightnfotis: I already read it! :-D
+ <tschwinge> Oh, I didn't. I read the week 7 one. Let me read week 8. ;-)
+ <nlightnfotis> ok. I am currently going through the assembly generated for
+ the sample program I have embedded my report.
+ <nlightnfotis> the weird thing is that the assembly generated is pretty
+ much the same for the program with 1 and 2 goroutine functions (with the
+ obvious difference that the one with 2 goroutine functions has 1 more
+ goroutine in it's assembly code)
+ <nlightnfotis> I can not understand why it is that when I have 1 goroutine,
+ an exception is triggered, but when I am having two (which are 99%
+ identical) it seems to be executed.
+ <nlightnfotis> and I do not understand why the exception is triggered when
+ I manually use a goroutine.
+ <nlightnfotis> To my understanding so far, there is at least 1 (kernel)
+ thread created at program startup to run main. The same thread gets
+ created to run a new goroutine (goroutines get associated with kernel
+ threads)
+ <nlightnfotis> and it's obvious from the assembly generated.
+ <nlightnfotis> go_init_main (the main function for go programs) starts with
+ a .cfi_startproc
+ <nlightnfotis> the same piece of code (.cfi_startproc) starts a new kernel
+ thread (on which a goroutine runs)
+ <tschwinge> nlightnfotis: Re your two-goroutines example: in that case I
+ assume, you're directly returning from the main function and the program
+ terminates normally. ;-)
+ <tschwinge> nlightnfotis: Studying the assembly code for this will be too
+ verbose, too low-level. What we need is a trace of steps that happen
+ until the error.
+ <nlightnfotis> tschwinge, that must be it, but it should trigger the bug,
+ since it still has at least one goroutine (and one is known to trigger
+ the bug)
+ <tschwinge> nlightnfotis: I guess the program exits before the first
+ gorouting would be scheduled for execution.
+ <nlightnfotis> the assembly for the goroutines is identical. You can't tell
+ one from the other. The only change is that it has 2 of these sections
+ instead of one
+ <nlightnfotis> actually it's the same for the first one
+ <tschwinge> nlightnfotis: I very much assume that the issue is not due to
+ the code generated by the Go compiler (which you're seeing in the
+ assembly code), but rather due to the runtime code in the libgo library.
+ <nlightnfotis> I didn't think of it this way.
+ <tschwinge> ... that improperly interacts with our libpthread.
+ <nlightnfotis> so my research should focus on the runtime from now on?
+ <tschwinge> Improperly may well imply that our libpthread is at fault, of
+ course, as we discussed.
+ <tschwinge> Back to the one-gouroutine case (that shows the assertion
+ failure). Simple case: one goroutine, plus the "main" thread.
+ <tschwinge> We need to get an understanding of the steps that happen until
+ the error happens.
+ <tschwinge> As this is a parallel problem, and it is involving "advanced"
+ things (such as setcontext), I would not trust GDB too much when used on
+ this code.
+ <nlightnfotis> I will have to manually step through the source myself,
+ right?
+ <tschwinge> What I would do, is add printf's (or similar) into the code at
+ critical points, to get an udnerstanding of what's going on.
+ <tschwinge> Such critical points are: pthread_create, setcontext,
+ swapcontext.
+ <nlightnfotis> It sounds like a good idea. Anything else to note?
+ <tschwinge> That way, you can isolate the steps required to trigger the
+ assertion failure.
+ <tschwinge> For example, it could be something like: makecontext,
+ swapcontext, pthread_creat, boom.
+ <nlightnfotis> pthread_create_internal is failing at an assertion. I wonder
+ what would happen if I remove that assertion.
+ <tschwinge> Not without understanding what the error is, and why it is
+ happening (which steps lead to it). We don't usually do »voodoo
+ computing and programming by coincidence«.
+ <nlightnfotis> tschwinge, I also figured out something. If it is a
+ libpthread issue, it should also get triggered when a simple C program
+ creates a thread (assuming _pthread_create is causing the issue)
+ <nlightnfotis> so maybe I should write a C program to test that
+ functionality and see if it provides any further clues?
+ <tschwinge> nlightnfotis: That's precile what the goal of »isolate the
+ steps required to trigger the assertion failure« is about: reduce the big
+ libgo code to a few function calls required to reproduce the problem.
+ <tschwinge> nlightnfotis: I simple C program just doing pthread_create
+ evidently does not fail.
+ <tschwinge> nlightnfotis: I assume you have a Go program dynamically linked
+ to the libgo you build?
+ <nlightnfotis> yes. To the latest go build from the source (4.9)
+ <nlightnfotis> *gccgo build from source
+ <braunr> removing an assertion is usually extremely bad practice
+ <tschwinge> Then you can just do something like make target-libgo (IIRC)
+ (or instead: cd i686-pc-gnu/libgo/ && make) to rebuild your changed
+ libgo, and then re-run the Go program.
+ <braunr> the thought of randomly removing assertions shouldn't even reach
+ your mind !
+ <nlightnfotis> braunr: even if it is not permanent, but an experiment?
+ <braunr> yes
+ <nlightnfotis> can you explain to me why?
+ <tschwinge> nlightnfotis: <tschwinge> Not without understanding what the
+ error is, and why it is happening (which steps lead to it). We don't
+ usually do »voodoo computing and programming by coincidence«.
+ <braunr> an assertion exists to make sure something that should *never*
+ happen never happens
+ <braunr> removing it allows such events to silently occur
+ <teythoon> braunr: that's the theory, yes, to check invariants
+ <braunr> i dont' know what you mean by using assertions for "an experiment"
+ <teythoon> unfortunately some people use assert for error handling :/
+ <braunr> that's wrong
+ <braunr> and i dont't remember it to be the case in libpthread
+ <braunr> nlightnfotis: can you point the faulting assertion again there
+ please ?
+ <nlightnfotis> braunr: sure: Assertion `({ mach_port_t ktid =
+ __mach_thread_self (); int ok = thread->kernel_thread == ktid;
+ <nlightnfotis> __mach_port_deallocate ((__mach_task_self + 0), ktid); ok;
+ })' failed.
+ <braunr> so basically, thread->kernel_thread != __mach_thread_self()
+ <braunr> this code is run only for num_threads == 1
+ <braunr> but has there been any thread destruction before ?
+ <nlightnfotis> no. To my understanding kernel threads in the go runtime
+ never get destroyed (comments seem to support that)
+ <braunr> IOW: is it certain the only thread left *is* the main thread ?
+ <braunr> hm
+ <braunr> intuitively, i'd say this is wrong
+ <braunr> i'd say go doesn't destroy threads in most cases, but something in
+ the go runtime must have done it already
+ <braunr> i'm not even sure the main thread still exists
+ <braunr> check that
+ <braunr> where is the go code you're working on ?
+ <nlightnfotis> there are 3 files of interest
+ <braunr> i'd like the whole sources please
+ <nlightnfotis> I will find it in a moment
+ <tschwinge> braunr: GCC Git clone, tschwinge/t/hurd/go branch.
+ <nlightnfotis> it is <gcc_root>/libgo/runtime/runtime.h
+ <nlightnfotis> it is <gcc_root>/libgo/runtime/proc.c
+ <braunr> tschwinge: thanks
+ <tschwinge> braunr: git://
+ <nlightnfotis> I will provide links on github
+ <braunr> nlightnfotis: i sayd the whole sources, why do you insist on
+ giving me separate files ?
+ <nlightnfotis> for checking it out quickly
+ <nlightnfotis> oh I misunderstood that sorry
+ <nlightnfotis> thought you wanted to check out thread creation and
+ destruction and that you were interested only in those specific files
+ <braunr> tschwinge: is it completely contained there or are there external
+ libraries ?
+ <tschwinge> braunr: You mean libgo?
+ <braunr> tschwinge: possibly
+ <nlightnfotis> tschwinge, I just made sure that yeah programs are
+ dynamically linked against the compiler's libgo
+ <nlightnfotis>
+ <braunr> does libgo come from gcc sources ?
+ <nlightnfotis> yeah
+ <braunr> ok
+ <nlightnfotis> go files on gcc sources are split under two directories: go,
+ which contains the frontend go, and libgo which contains the libraries
+ and the runtime code
+ <tschwinge> braunr: darnassus:~tschwinge/tmp/gcc/ is a recent
+ build, with sources in $PWD/../go/.
+ <tschwinge> braunr: libgo is in i686-unknown-gnu0.3/libgo/.libs/
+ <nlightnfotis> so tschwinge to roundup for this week I should print debug
+ around the "hotspots" and see if I can extract more information about
+ where the specific problem is triggered right?
+ <tschwinge> nlightnfotis: Yes, for a start.
+ <braunr> nlightnfotis: identify the main thread, make sure it doesn't exit
+ <nlightnfotis> noted.
+ <nlightnfotis> braunr: do you have an idea about the issue I described
+ earlier? The one with the 1 goroutine triggering the bug, but the 2
+ exiting successfully but with no output?
+ <braunr> nlightnfotis: i didn't read
+ <nlightnfotis> do you have 2 mins to read my report? I describe the issue
+ <braunr> something messed up in the context i suppose
+ <tschwinge> nlightnfotis: Uhm, I already explained that issue?
+ <braunr> you did ?
+ <nlightnfotis> tschwinge, I know, don't worry. I am trying to get all the
+ insight I can get.
+ <nlightnfotis> you mentioned that the scheduler might have an issue and
+ that the main thread returns before the goroutines execu
+ <nlightnfotis> *execute
+ <nlightnfotis> right?
+ <tschwinge> It is the normal thing for a process to terminate normally when
+ the main function returns. I would expect Go to behave the same way.
+ <braunr> "Now, if we change one of the say functions inside main to a
+ goroutine, this happens"
+ <braunr> how do you change it ?
+ <tschwinge> Or am I confused?
+ <braunr> tschwinge: i don't remember exactly
+ <nlightnfotis> braunr: from say("world") to go say("world")
+ <nlightnfotis> tschwinge, yeah I get that. What I still have not understood
+ is what is it specifically about the 2 goroutines that doesn't trigger
+ the issu when 1 goroutine does.
+ <nlightnfotis> You said that it might have something to do with the
+ scheduler; it does seem like a good explanation to me
+ <tschwinge> nlightnfotis: My understanding still is that the goroutinges
+ don't get executed before the main thread exits.
+ <braunr> which scheduler ?
+ <nlightnfotis> braunr: the runtime (go) scheduler.
+ <nlightnfotis> tschwinge, Yeah, they don't. But still, with 1 goroutine:
+ you get into main, attempt to execute it, and bam! With two, it should be
+ the same, but strangely it seems to exit main without an issue
+ <nlightnfotis> (attempt to execute the goroutine)
+ <braunr> why should it be the same ?
+ <nlightnfotis> braunr: seeing as one goroutine has problems, I can't see
+ why two wouldn't. At least one of the two should result in an exception.
+ <braunr> nlightnfotis: why ?
+ <braunr> nlightnfotis: they do have the problem
+ <braunr> they don't run
+ <braunr> they just don't run into that assertion, probably because there is
+ more than one thread
+ <nlightnfotis> wait a minute. You imply that they fail silently? But still
+ end up in the same situation
+ <braunr> yes
+ <braunr> in which case it does look like a go scheduler problem
+ <nlightnfotis> if I understood it correctly, that assertion fails when it
+ is only 1 thread?
+ <braunr> yes
+ <braunr> and since the main thread is always correct, i expect the main
+ thread has exited
+ <braunr> which this happens because the one thread left is *not* the main
+ thread
+ <braunr> (which is a libpthread bug)
+ <braunr> but it's a bug we've not seen because we don't have applications
+ creating threads while exiting
+ <nlightnfotis> I think I got it now.
+ <braunr> try to put something like getchar() in your go program
+ <braunr> something that introduces a break
+ <braunr> so that the main thread doesn't exit
+ <nlightnfotis> oh right. Thanks for that. And sorry tschwinge I reread what
+ you said, it seems I had misinterpreted what you suggested.
+ <tschwinge> braunr: If you're interested: for a Go program triggering the
+ asserition, I don't see any thread exiting (see
+ darnassus:~tschwinge/tmp/gcc/a.go, run: cd ~tschwinge/tmp/gcc/
+ && ./a.out) -- but perhaps I've been looking for the wrong things in l_.
+ File l is without a goroutine. Have to leave now, sorry.
+ <tschwinge> braunr: If you want to rebuild: gcc/gccgo -B gcc -B
+ i686-unknown-gnu0.3/libgo ../a.go -Li686-unknown-gnu0.3/libgo/.libs
+ -Wl,-rpath,i686-unknown-gnu0.3/libgo/.libs
+ <braunr> tschwinge: no i won't touch anything
+ <braunr> but thanks
+# IRC, freenode, #hurd, 2013-08-19
+ <youpi> nlightnfotis: how are you going with gcc go?
+ <nlightnfotis> I was print debugging all the week.
+ <nlightnfotis> I can tell you I haven't noticed anything weird so far.
+ <nlightnfotis> But I feel I am close to the solution
+ <nlightnfotis> I have not written my report yet.
+ <nlightnfotis> I will write it maximum until wednesday
+ <nlightnfotis> I hope I will have figured it all out until then
+ <pinotree> a report is not for writing solutions, but for the progress
+ <youpi> yes
+ <youpi> it's completely fine to be saying "I've been debugging, not found
+ anything yet"
+ <pinotree> results or not, always write your reports on time, so your
+ mentor(s) know what you are doing
+ <nlightnfotis> I see. Would you like me to write it right now, or is it
+ okay to write it a day or two later?
+ <hacklu__> nlightnfotis: FYI. this week my report is not finished. just
+ state some problem I face now.
+ <youpi> nlightnfotis: I'd say better write it now
+ <nlightnfotis> youpi: Ok I will write it and tell you when I am done with
+ it.
+ <nlightnfotis> youpi: here is my partial report describing what my course
+ of action looked like this
+ week.
+ <nlightnfotis> of course, I will write in a day or two (hopefully having
+ figured out the whole situation) an exhaustive report describing
+ everything I did in detail
+ <nlightnfotis> youpi: I have written my (partial) report describing how I
+ went about this week
+ <youpi> nlightnfotis: good, thanks!
+ <nlightnfotis> youpi: please note that this is not an exhaustive link of my
+ findings or course of action, it merely acts as an example to demonstrate
+ the way I think and how I go about every day.
+ <nlightnfotis> I will write an exhaustive report of everything I did so
+ far, when I figure out what the issue is, and I feel I am close.
+ <youpi> well, you don't need to explain all bits in details
+ <youpi> this is fine to show an example of how you went
+ <youpi> but please also provide a summary of your other findings
+ <nlightnfotis> oh okay, I will keep this in mind. :)
+# IRC, freenode, #hurd, 2013-08-22
+ < nlightnfotis> if I want to rebuild libpthread, I have to embed it into
+ eglibc's source, then build?
+ < pinotree> or pick the debian sources, patch libpthread there and rebuild
+ < nlightnfotis> that's most likely what I am going to do. Thanks pinotree.
+ < pinotree> yw
+ < braunr> nlightnfotis: i usually add my patches on top of the debian glibc
+ ones, yes
+ < braunr> it requires some tweaking
+ < braunr> but it's probably the easiest way
+ < nlightnfotis> braunr: I was studying my issues with gcc, and everyday I
+ was getting more and more confident it must be a libpthread issue
+ < nlightnfotis> and I figured out, that I might wanna play with libpthread
+ this time
+ < braunr> it probably is but
+ < braunr> i'm not so sure you should dive there
+ < nlightnfotis> why not?
+ < braunr> because it can be worked around in go
+ < braunr> i had a test for you last time
+ < braunr> do you remember what it was ?
+ < nlightnfotis> nope :/ care to remind it?
+ < braunr> iirc, it was running the go test you did but with an additional
+ instruction in the main function, that pauses
+ < braunr> something like getchar() in c
+ < braunr> to make sure main doesn't exit while the goroutines are still
+ running
+ < braunr> i'm almost positive that the bug you're seeing is main returning
+ and libpthread beleiving it's acting on the main thread because there is
+ only one left
+ < nlightnfotis> oh that's easy, I can do it now. But it's probably what
+ thomas had suggested: go routines may not be running at all.
+ < braunr> they probably aren't
+ < braunr> and that's a context bug
+ < braunr> not a libpthread bug
+ < braunr> and that's what you should focus on
+ < braunr> the libpthread bug is minor
+ < nlightnfotis> which is strange, because I had studied the assembly code
+ and it the code for the goroutine was there
+ < nlightnfotis> anyway I will proceed with what you suggested
+ < braunr> yes please
+ < braunr> that's becoming important
+ < nlightnfotis> would you mind me dumping some of my findings for you to
+ evaluate/ post on opinion on?
+ < braunr> no
+ < braunr> please do so
+ < nlightnfotis> I have found that the go runtime starts with a total number
+ of threads == 1
+ < braunr> nlightnfotis: as all processes
+ < nlightnfotis> I would guess that's because of using fork ()
+ < nlightnfotis> oh so it's ok
+ < braunr> there always is a main thread
+ < braunr> even for non-threaded applications
+ < nlightnfotis> yeah, that I know. The runtime proceeds to create
+ immediately one more.
+ < braunr> then it's 2
+ < nlightnfotis> and that's ok, it doesn't have an issue with that
+ < nlightnfotis> yep
+ < nlightnfotis> the issue begins when it tries to create the 3rd one
+ < braunr> hum
+ < braunr> from what i remember
+ < nlightnfotis> it happily goes through the go runtime's kernel thread
+ allocation function (runtime_newm())
+ < braunr> you also had an issue with the first goroutine
+ < nlightnfotis> that's with 1 go routine
+ < braunr> ok
+ < braunr> so 1 goroutine == 3 threads
+ < nlightnfotis> it seems so yes.
+ < braunr> depending on how the go scheduler is able to assign goroutines to
+ kernel threads i suppose
+ < nlightnfotis> mind you, (disclaimer: I am not so sure about that) that go
+ must be using one extra thread for the runtime scheduler and garbage
+ collector
+ < braunr> that's ok
+ < nlightnfotis> so that's where the two come from
+ < braunr> and expected from a modern runtime
+ < nlightnfotis> the third must be the go routime
+ < nlightnfotis> routine
+ < braunr> hum have to go
+ < braunr> brb in a few minutes
+ < braunr> keep posting
+ < nlightnfotis> it's ok take your time
+ < nlightnfotis> I will be here
+ < braunr> but i may not ;p
+ < braunr> in fact i will not
+ < braunr> i have like 15 mins ;)
+ < braunr> nlightnfotis: ^
+ < nlightnfotis> I am trying what you told me to do with go
+ < nlightnfotis> it's ok if you have to go, I will continue investigating
+ and be back tomorrow
+ < braunr> ok
+ < nlightnfotis> braunr: I tried what you asked me to do, both we waiting to
+ read a string from stdin and with waiting to read an int from stdin
+ < nlightnfotis> it never waits, it still aborts with the assertion failure
+ < nlightnfotis> both with one and two go routines
+ < nlightnfotis> dumping it here just for the log, running the same code
+ without waiting for input results in two threads created (1 for main and
+ 1 for runtime, most likely) and "normal" execution.
+ < nlightnfotis> normal as in no assertion failure,
+ < nlightnfotis> it seems to skip the goroutines altogether
+# IRC, freenode, #hurd, 2013-08-23
+ < braunr> nlightnfotis: can i see your last go test code please ? the one
+ with the read at the end of main
+ < nlightnfotis> braunr sure
+ < nlightnfotis> sorry I had gone to the toilet, now I am back
+ < nlightnfotis> I will send it right now
+ < nlightnfotis> braunr:
+ < nlightnfotis> it crashes when it attempts to create the 3rd thread (the
+ 1st goroutine), with the assertion fail
+ < nlightnfotis> if you remove the Scanf it will not fail, return 0, but
+ only create 2 threads (skip the goroutines alltogether)
+ < braunr> can you add a print right before main exits please ?
+ < braunr> so we know when it does
+ < nlightnfotis> doing it now
+ < nlightnfotis> braunr: If I enter a print statement right before main
+ exits, the assertion failure is triggered. If I remove it, it still runs
+ and creates only 2 threads.
+ < braunr> i don't understand
+ < braunr> 14:42 < nlightnfotis> it crashes when it attempts to create the
+ 3rd thread (the 1st goroutine), with the assertion fail
+ < braunr> why don't you get that ?
+ < nlightnfotis> This seems like having to do with the runtime. I mean, I
+ have seen the emitted assembly from the compiler, and the goroutines are
+ there. Something in the runtime must be skipping them
+ < braunr> context switching seems buggy
+ < nlightnfotis> if it's only goroutines in main
+ < nlightnfotis> if there's also something else in main, the assertion
+ failure is triggered.
+ < braunr> i want you to add a printf right before main exits, from the code
+ you pasted
+ < nlightnfotis> I did. It acts the same as before.
+ < braunr> do you see that last printf ?
+ < nlightnfotis> no. It aborts before that
+ < nlightnfotis> :q
+ < braunr> find a way to make sure the output buffer is flushed
+ < braunr> i don't know how it's done in go
+ < nlightnfotis> mistype the :q, was supposed to do it vim
+ < nlightnfotis> braunr will do right away
+ < nlightnfotis> there is one thing I still can not understand: Why is it
+ that two threads are ok, but when the next is going to get created, the
+ assertion is triggered.
+ < braunr> nlightnfotis: the assertion is triggered because a thread is
+ being created while there is only one thread left, and this thread isn't
+ the main thread
+ < braunr> so basically, the main thread has exited, and another (the last
+ one) is trying to create one
+ < nlightnfotis> the other one might be the runtime I guess. Let me check
+ out quickly what you suggested
+ < braunr> the main thread shouldn't exit at all
+ < braunr> so something with context switching is wrong
+ < nlightnfotis> the thing is: it doesn't seem to exit when this happens. My
+ debug statements (in the runtime) suggest that there are at least 2
+ threads active, kernel threads don't get destroyed in gccgo
+ < braunr> 14:52 < braunr> so something with context switching is wrong
+ < braunr> how well have the context switching functions been tested ?
+ < nlightnfotis> to be honest I have not tested them; up until this point I
+ trusted they worked. Should I also take a look at them?
+ < braunr> how can you trust them ?
+ < braunr> they've never been used ..
+ < braunr> thomas added them recently if i'm right
+ < braunr> nothing has been using them except go
+ < braunr> piece of advice: don't trust anything
+ < nlightnfotis> I think they were in before, and thomas recently patched
+ them!
+ < braunr> they were in, but didn't work
+ < braunr> (if i'm right)
+ < braunr> nlightnfotis: you could patch libpthread to monitor the number of
+ threads
+ < braunr> or the go runtime, idk
+ < nlightnfotis> I have done so on the go runtime
+ < nlightnfotis> that's where I am getting the number of threads I
+ report. That's straight out from the scheduler's count.
+ < braunr> threads can exit by calling pthread_exit() or returning from the
+ thread routine
+ < braunr> make sure you catch both
+ < braunr> also check for pthread_cancel(), although i don't expect any in
+ go
+ < nlightnfotis> braunr: Should I really do that? I mean, from what I can
+ see in gccgo's comments, Kernel threads (m) never go away. They are added
+ to a pool of m's waiting for work if there is no goroutine running on
+ them
+ < nlightnfotis> I mean, I am not so sure they exit at all
+ < braunr> be sure
+ < braunr> point me the code please
+ < nlightnfotis>
+ < nlightnfotis> this is where it get's stated that m's never go away
+ < nlightnfotis> and at line 257 you can see the pool
+ < nlightnfotis> and wait for me to find the code that actually releases an
+ and places into the pool
+ < nlightnfotis> yep found it
+ < nlightnfotis> line 817 mput
+ < nlightnfotis> puts a kernel thread given as parameter to the pool
+ < nlightnfotis> another proof of the theory is at line 1177. It states:
+ "This point is never reached, because scheduler does not release os
+ threads at the moment."
+ < braunr> fetching git repository, bit busy, i'll have a look in 5-10 mins
+ < nlightnfotis> oh it's ok, I had pointed you to the file directly on
+ github to check it out instantly, but never mind, the file is
+ <gccroot>/libgo/runtime/proc.c
+ < braunr> damn github is so slow ..
+ < braunr> nlightnfotis: i much prefer my own text interface :)
+ < nlightnfotis> braunr: just out of curiosity what's your setup? I use vim
+ mainly (not that I am a vim expert or anything, I only know the basics,
+ but I love it)
+ < braunr> same
+ < braunr> nlightnfotis: add a trace at that comment to make SURE threads do
+ not exit
+ < braunr> you *cannot* get the libpthread assertion with more than 1 thread
+ < braunr> grep for pthread_exit() too
+ < nlightnfotis> will do it now. It will take about an hour to compile
+ though.
+ < braunr> i don't understand the stack trick at the start of runtime_mstart
+ < braunr> ah splitstack ..
+ < nlightnfotis> I think I should try cross compiling gcc, and then move
+ files on the hurd. It would be so much faster I believe.
+ < braunr> than what ?
+ < nlightnfotis> building gcc on the hurd
+ < nlightnfotis> I remember it taking about 10minutes with make -j4 on the
+ host
+ < nlightnfotis> it takes 45-50 minutes on the vm (kvm enabled)
+ < braunr> but you can merely rebuild the files you've changed
+ < nlightnfotis> I feel stupid now...
+ < braunr> nlightnfotis: have you tried setting GOMAXPROCS to 1 ?
+ < nlightnfotis> not really, but from what I know GOMAXPROCS defaults to 1
+ if not set
+ < braunr> again, check that
+ < braunr> take the habit of checking things
+ < nlightnfotis> braunr: yeah sorry for that. I have checked these things
+ out before they don't come out of my head I just don't remember exactly
+ where I had seen this
+ < braunr> what you can also do is use gdb to catch the assertion and check
+ the number of threads at that time, as well as the number of threads as
+ seen by libpthread
+ < nlightnfotis> braunr: line 492 file proc.c: runtime_gomaxprocs = 1;
+ < braunr> also see runtime.LockOSThread
+ < braunr> to make sure the main thread is locked to its own pthread
+ < nlightnfotis> I can see in line 529 of the same file that the first
+ thread is getting locked
+ < nlightnfotis> the new threads that get initialised are non main threads
+ < braunr> if(!runtime_sched.lockmain) runtime_UnlockOSThread();
+ < braunr> i'm suggesting you set runtime_sched.lockmain
+ < braunr> so it remains true for the whole execution
+ < braunr> this code looks like a revamp of plan9 lol
+ < nlightnfotis> it is
+ < nlightnfotis> in the paper from Ian Lance Taylor describing gccgo he
+ states somewhere that the original go compilers (the 3gs) are a modified
+ version of plan9's C compiler, and that gccgo tries to follow them
+ < nlightnfotis> they differ in a lot of ways though
+ < nlightnfotis> the 3gs generate a lot of code during link time
+ < nlightnfotis> gccgo follows the standard gcc procedures
+ < braunr> eh :D
+ < nlightnfotis> go -> gogo -> generic -> gimple -> rtl -> object
+ < nlightnfotis> that's how it flows as far as I recall
+ < nlightnfotis> gogo is an internal representation of go's structure inside
+ the gccgo frontend
+ < nlightnfotis> that's why you see many functions with gogo in their name
+ < nlightnfotis> I just revisited the paper: gogo is there to make it easy
+ to implement whatever analysis might seem desirable. It mirrors however
+ the Go source code read from the input files
+ < braunr> nlightnfotis: what are you trying now ?
+ < nlightnfotis> I am basically studying the runtime's source code while
+ waiting for gccgo to compile on the Hurd
+ < nlightnfotis> yes I did the stupid whole recompilation again. :/
+ < braunr> nlightnfotis: compile for what ?
+ < braunr> what test ?
+ < nlightnfotis> to check out to see if M's really are added to the pool
+ instead of getting deleted
+ < braunr> nlightnfotis: but how ?
+ < nlightnfotis> braunr: I have added a statement in mput if we get there
+ first, and secondly the number of threads that the runtime scheduler
+ knows that are waiting (are in the pool of m's waiting for work)
+ < braunr> ok
+ < braunr> when you can, i'd really like you to do this test :
+ < braunr> 15:55 < braunr> what you can also do is use gdb to catch the
+ assertion and check the number of threads at that time, as well as the
+ number of threads as seen by libpthread
+ < nlightnfotis> the number of threads required by libpthread is gonna need
+ me to recompile the whole eglibc right?
+ < braunr> no
+ < braunr> just print it with gdb
+ < nlightnfotis> oh, ok
+ < braunr> it's __pthread_num_threads
+ < nlightnfotis> is gdb reliable? I remember thomas telling me that I can't
+ trust gdb at this point in time
+ < braunr> and also __pthread_total
+ < braunr> really ?
+ < braunr> i don't see why not :/
+ < braunr> youpi: any idea about what nlightnfotis is speaking of ?
+ < nlightnfotis> I may have misunderstood it; don't take it by heart
+ < nlightnfotis> I don't wanna put words in other people's mouths because I
+ misunderstood something
+ < braunr> sure
+ < braunr> that's my habit to check things
+ < youpi> braunr: nope
+ < braunr> youpi: and am i right when i say we don't use context functions
+ on the hurd, and they're likely to be incomplete, even with the recent
+ changes from thomas ?
+ < braunr> (mcontext, ucontext)
+ < nlightnfotis> braunr: this is what had been said: 08:46:30< tschwinge> As
+ this is a parallel problem, and it is involving "advanced" things (such
+ as setcontext), I would not trust GDB too much when used on this code.
+ < pinotree> if thomas' changes were complete and polished, i guess he would
+ have sent them upstream already
+ < braunr> i see but
+ < braunr> you can normally trust gdb for global variables
+ < nlightnfotis> Didn't post it as an objection; I posted it because I felt
+ bad putting the wrong words on other people's mouths, as I said
+ before. So I posted his original comment which was more authoritative
+ than my interpretation of it
+ < braunr> i wonder if there is a tunable to strictly map one thread to one
+ goroutine
+ < braunr> nlightnfotis: more focus on the work, less on the rest please
+ < nlightnfotis> Did I do something wrong?
+ < braunr> you waste too much time apologizing
+ < braunr> for no reason
+ < braunr> nlightnfotis: i suppose you don't use splitstack, right ?
+ < nlightnfotis> no I didn't
+ < nlightnfotis> and here's something interesting: The code I just added, in
+ mput, to see if threads are added in the pool. It's not there, no matter
+ what I run
+ < nlightnfotis> So it seems that we the runtime is not reaching mput.
+ < nlightnfotis> Could this be normal behavior? I mean, on process
+ termination just release the resources so mput is skipped?
+ < braunr> i don't know the code well enough to answer that
+ < braunr> check closer to the lower interface
+# IRC, freenode, #hurd, 2013-08-25
+ < nlightnfotis> braunr: what is initcontext supposed to be doing?
+ < braunr> nlightnfotis: didn't look
+ < braunr> i'll take a look later
+ < nlightnfotis> braunr: I am buffled by it. It seems to be doing nothing on
+ the Hurd branch and nothing in the Linux branch either. Why call a
+ function that does nothing? (it doesn't only seem to do nothing, I have
+ confirmed it)
+ < nlightnfotis> youpi: I was wondering if you could explain me
+ something. What is the initcontext function supposed to be doing?
+ < youpi> you mean initcontext ?
+ < nlightnfotis> yes
+ < youpi> ergl
+ < youpi> you mean makecontext?
+ < nlightnfotis> no initcontext. I am faced with this in the goruntime. It's
+ called in it, but it is doing nothing. Neither in the Hurd tree, nor in
+ the Linux one
+ < youpi> I don't know what initcontext is
+ < youpi> where do you read it?
+ < nlightnfotis> youpi: let me show you
+ < nlightnfotis>
+ < nlightnfotis> and it is called in quite a few places
+ < youpi> it's not doing nothing, see other implementations
+ < pinotree> if SETCONTEXT_CLOBBERS_TLS is not defined, initcontext and
+ fixcontext do nothing
+ < pinotree> otherwise (presuming if setcontext clobbers tls) there are two
+ implementations for solaris/x86_64 and netbsd
+ < youpi> I don't think we have the tls clobber bug
+ < youpi> so these functions being empty is completely fine
+ < nlightnfotis> pinotree: oh, you mean it's used as a workaround for these
+ two systems only?
+ < youpi> yes
+ < pinotree> yes
+ < nlightnfotis> That makes sense. Thanks both of you for the help :)
+ < nlightnfotis> youpi: if this counts as some progress, I have traced the
+ exact bootstrapping sequence of a new go process. I know a good deal of
+ what is done from it's spawn to it's end. There are some things I wanna
+ sort out, and later tonight I will write my report for it to be ready for
+ tomorrow.
+ < youpi> good
+# IRC, freenode, #hurd, 2013-08-26
+ < nlightnfotis> Hi everyone, my report is here
+ < youpi> nlightnfotis: you should clearly put printfs inside libpthread
+ < youpi> to check what is happening with the ktids
+ < nlightnfotis> youpi: yep, that's my next course of action. I just want to
+ spend some more time in the go runtime to make sure that I understand the
+ flow perfectly, and to make sure that it is not the runtime's fault
+ < braunr> nlightnfotis: did you try gdb to print the number of threads ?
+ < youpi> nlightnfotis: to build it, the easiest way is to start building
+ eglibc, and when you see it compiling C files (i.e. run i486-gnu-gcc-4.7
+ etc.)
+ < youpi> stop it
+ < youpi> and go into build/hurd-i386-libc, and run "make others" from there
+ < nlightnfotis> braunr: that was my plan for today or tomorrow :)
+ < braunr> start building *debian* glibc
+ < youpi> there's perhaps some way to only build libpthread, but I don't
+ remember
+ < braunr> nlightnfotis: ok
+ < braunr> youpi: i suggested he tried gdb first
+ < youpi> why not
+ < braunr> if you need quick glibc builds, you can use darnassus
+ < nlightnfotis> braunr: how much time on average should I expect it to
+ take?
+ < youpi> it highly depends on the machine
+ < youpi> it can be hours
+ < youpi> or a few minutes
+ < youpi> depending you already have a built tree, a fast disk, etc.
+ < braunr> make lib others on darnassus takes around 30 minutes
+ < braunr> a complete dpkg-buildpackage from fresh sources takes 5-6 hours
+ < braunr> make others from a built tree is very quick
+ < braunr> a few minutes at most
+ < braunr> nlightnfotis: i don't see any trace of thread exiting in your
+ report, is that normal ?
+ < nlightnfotis> yeah, I guess, since they don't exit prematurely, they are
+ released along with other resources at the process' exit
+ < braunr> i'll rephrase
+ < braunr> you said last time that you saw a function never got called
+ < braunr> i assumed it was because a thread exited prematurely
+ < nlightnfotis> oh I sorted it out with the help of youpi and pinotree
+ yesterday
+ < braunr> that's different
+ < braunr> i'm not talking about the function that does nothing
+ < braunr> i'm talking about the one never called
+ < nlightnfotis> oh, go on then,
+ < braunr> i don't remember its name
+ < braunr> anyway
+ < nlightnfotis> abort()?
+ < braunr> i hope abort doesn't get called :)
+ < nlightnfotis> it doesn't
+ < braunr> i thought it was the one right before
+ < braunr> what i mean is
+ < nlightnfotis> oh runtime_mstart, it does get called
+ < braunr> add traces at thread exit points
+ < nlightnfotis> I sorted it out too
+ < braunr> make *sure* threads don't exit
+ < nlightnfotis> it get's called to start the kernel thread created at
+ process spawn at the runtime_schedinit
+ < braunr> if they really don't, it's probably a context/tls issue
+ < nlightnfotis> I will do this right now.
+ < nlightnfotis> braunr: if it's a context/tls issue it's libpthread's
+ problem?
+# IRC, freenode, #hurd, 2013-09-02
+ <nlightnfotis> Hello! My report for this week is online:
+ <braunr> nlightnfotis: there always is a signal thread in every hurd
+ program
+ <braunr> nlightnfotis: i also pointed out that there are two variables
+ involved in counting threads in libpthread, the other one being
+ __pthread_num_threads
+ <braunr> again, more attention to work and details, less showmanship
+ <braunr> i'm tired of repeating it
+ <youpi> nlightnfotis: doesn't backtrace work in gdb to tell you what
+ 0x01da48ec is?
+ <youpi> also, do you have libc0.3-dbg installed?
+ <nlightnfotis> braunr: __pthread_num_threads reports is 4.
+ <braunr> then why isn't it in your report ?
+ <braunr> it's acceptable that you overlook it
+ <nlightnfotis> and youpi: yeah I have got the backtrace, but 0x01da48ec is
+ ?? () from /lib/i386-gnu/
+ <braunr> it's NOT when someone else has previously mentioned it to you
+ <youpi> nlightnfotis: only that line, no other line?
+ <nlightnfotis> it has 8 more youpi, the one after ?? is mach_msg ()
+ form/lib/gni386-gnu/
+ <braunr> yes mach_msg
+ <braunr> almost everything ends up in mach_msg
+ <youpi> you should probably pastebin somewhere the output of thread apply
+ all bt
+ <braunr> what's before that ?
+ <nlightnfotis> braunr: I don't know how I even missed it. I skimmed through
+ the code and only found __pthread_total and assumed that it was the total
+ number of threads
+ <braunr> nlightnfotis: i don't know either
+ <braunr> take notes
+ <nlightnfotis> before mach_msg ins __pthread_timedblock () from
+ /lib/i386-gnu/
+ <nlightnfotis> I will add it to pastebin in a second
+ <braunr> i find it very disappointing that after several weeks blocking on
+ this, despite all the pointers you've been given, you still haven't made
+ enough progress to reach the context switching functions
+ <braunr> last week, most progress was made when we talked together
+ <braunr> then nothing
+ <braunr> it seems that you disappear, apparently searching on your own
+ <braunr> but for far too long
+ <nlightnfotis> braunr: I do search on my own, yes,
+ <braunr> almost like exploiting being blocked not to make progress on
+ purpose ...
+ <braunr> but too much
+ <nlightnfotis> braunr: I am not doing this on purpose, I believe you are
+ unfair to me. I am trying to make as much progress as I can alone, and
+ reach out only when I can't do much more alone
+ <braunr> then why is it only now that we get replies to questions such as
+ "how much is __pthread_num_threads" ?
+ <braunr> why do you stop discussions for almost a week, just to find
+ yourself blocked again ?
+ <nlightnfotis> I was working on gcc, going through the runtime making sure
+ about assumptions and going through various other goroutine or not
+ programs through gdb
+ <braunr> that doesn't take a week
+ <braunr> clearly not
+ <braunr> last time we talked was
+ <braunr> 10:40 < nlightnfotis> braunr: if it's a context/tls issue it's
+ libpthread's problem?
+ <nlightnfotis> it did for me... honestly, what is it you believe I am doing
+ wrong? I too am frustrated by my lack of progress, but I am doing my best
+ <braunr> august 26
+ <nlightnfotis> yeah, I wanted to make sure about certain assumptions on the
+ gcc side. I don't want to start hacking on libpthread only to see that it
+ might have been something I msissed on the gcc side
+ <braunr> i told you
+ <braunr> it's probably not a libpthread issue
+ <braunr> the assertion is
+ <braunr> but it's minor
+ <braunr> it's not the realy problem, only a side effect
+ <braunr> i told you about __pthread_num_threads, why didn't you look at it
+ ?
+ <braunr> i told you about context switching functions, why nothing about it
+ ?
+ <braunr> doing a few printfs to check numbers and using gdb to check them
+ at break points should be quick
+ <braunr> when we talk,ed we had the results in a few minutes
+ <nlightnfotis> yeah, because I was guided, and that helped me target my
+ research. On my own things are quite different. I find out something
+ about gcc's behavior, then find out I need tons more information, and I
+ have a lot of things that I need to research to confirm any assumptions
+ from my side
+ <braunr> how did you miss the signal thread ?
+ <braunr> we even talked about it right here with hacklu
+ <braunr> i'll say it again
+ <braunr> if blocked more than one day, ask for help
+ <braunr> 2 days minimum each time is just too long
+ <nlightnfotis> I'm sorry. I will be online every day from now on and report
+ every 10 minutes, on my course of actions.
+ <nlightnfotis> I recognise that time is off the essence at this point in
+ time
+ <braunr> it's also NO
+ <braunr> NO
+ <braunr> *SIGH*
+ <hacklu> nlightnfotis: calm down. braunr just want to help you solve
+ problem quickly.
+ <braunr> 10 minutes is the other extreme
+ <hacklu> nlightnfotis: in my experiecence, if something block me, I will
+ keep asking him until I solve the problem.
+ <braunr> it's also very frustrating to see you answer questions quickly
+ when you're here, then wait days for unanswered questions that could have
+ taken little time if you kept being here
+ <braunr> this just gives the impression that you're doing something else in
+ parallel that keeps you busy
+ <braunr> and comfort me in believing you're not being serious enough
+ aboutit
+ <nlightnfotis> yeah, I understand that it gives that impression. The only
+ thing I can tell you now, is that I am *not* doing something else in
+ parallel. I am only trying to demonstrate some progress alone, and when
+ working alone things for me take quite some more time than when I am
+ guided
+ <braunr> hacklu: i'm actually the nervous one here
+ <nlightnfotis> braunr: ok, I understand I have dissapointed you. What would
+ you suggest me to do from now on?
+ <hacklu> braunr: :)
+ <braunr> manage your time correctly or you'll fail
+ <braunr> i'm not the main mentor of this project so it's not for me to
+ decide
+ <braunr> but if i were, and if i had to wait again for several days before
+ any notice of progress or blocking, i wouldn't even wait for the end of
+ the gsoc
+ <braunr> you're confronted with difficult issues
+ <braunr> tls, context switching, thread
+ <braunr> ing
+ <braunr> they're all complicated
+ <braunr> unless you're very experienced and/or gifted, don't assume you can
+ solve it on your own
+ <braunr> and the biggest concern for me is that it's not even the main
+ focus of your project
+ <braunr> you should be working on go
+ <braunr> on porting
+ <braunr> any side issues should be solved as quickly as possible
+ <braunr> and we're now in september ...
+ <nlightnfotis> go is working quite alright. It's goroutines that have
+ issues.
+ <braunr> nlightnfotis: same thing
+ <braunr> goroutines are part of go as far as i'm concerned
+ <braunr> and they're working too, something in the hurd isn't
+ <braunr> so it's a side issue
+ <braunr> you're very much entitled to ask as much help as you need for side
+ issues
+ <braunr> and i strongly feel you didn't
+ <nlightnfotis> yeah, you're right. I failed on that aspect, mainly because
+ of the way I work. I wanted to show some progress on my own, and not be
+ here and spam all day. I felt that spamming questions all day would
+ demonstrate incompetence from my side
+ <nlightnfotis> and I wanted to show that I am capable of solving my
+ problems on my own.
+ <braunr> well, in a sense it does, but that's not the skills we were
+ expecting from you so it's perfectly ok
+ <braunr> nlightnfotis: no development group, even in companies, in their
+ right mind, would expect you to grasp the low level dark details of an
+ operating system implementation in a few weeks ...
+ <nlightnfotis> braunr: ok, may I ask what you suggest to me that my next
+ course of action is?
+ <braunr> let me see
+ <braunr> nlightnfotis: your report mentions runtime_malg
+ <nlightnfotis> yes, I runtime malg always returns a new goroutine
+ <braunr> nlightnfotis: what's the problem ?
+ <nlightnfotis> a new m created is assigned a new goroutine via runtime_malg
+ <nlightnfotis> what happens to that goroutine? Is it destroyed? Because it
+ seems to be a bogus goroutine. Why isn't the kernel thread instantly
+ picking the one goroutine available at the global goroutine pool?
+ <braunr> let's see if it's that hard to figure out
+ <nlightnfotis> seeing as m's and g's have a 1:1 (in gccgo) relationship,
+ and a new kernel thread is created everytime there is a new goroutine
+ there to run.
+ <braunr> are you sure about that 1:1 relationship ?
+ <braunr> i hardly doubt it
+ <braunr> highly*
+ <nlightnfotis> yeah, that's what I thought too, but then again, my research
+ so far shows that when a new goroutine is created, a new kernel thread
+ creation follows suit
+ <nlightnfotis> what I have mentioned of course, happens in runtime_newm
+ <braunr> nlightnfotis: that's when you create a new m, not a new g
+ <nlightnfotis> yes, a new m is created when you create a new g. My issue is
+ that during m's creation, a new (bogus) g is created and assigned to the
+ m. I am looking into what happens to that.
+ <braunr> nlightnfotis: "a new m is created when you create a new g", can
+ you point me to the code ?
+ <nlightnfotis> braunr: matchmg line 1280 or close to that. Creates new m's
+ to run new g's up to (mcpumax)
+ <braunr> "Kick off new m's as needed (up to mcpumax)."
+ <braunr> so basically you have at most mcpumax m
+ <nlightnfotis> yeah. but for a small number of goroutines (as for example
+ in my experiments), a new m is created in order to run a new g.
+ <braunr> runtime_newm is called only if mget(gp)) == nil
+ <braunr> be rigorous please
+ <braunr> when i ask
+ <braunr> 11:01 < braunr> are you sure about that 1:1 relationship ?
+ <braunr> this conclusively proves it's *false*
+ <braunr> so don't answer yes to that
+ <braunr> it's true for a small number of goroutines, ok
+ <braunr> and at startup
+ <braunr> because then, mget returns an existing m
+ <braunr> nlightnfotis: this g0 goroutine is described in the struct as
+ <braunr> G runtime_g0; // idle goroutine for m0
+ <braunr> runtime_malg builds it with just a stack
+ <braunr> apparently, that's the goroutine an m runs when there are no g
+ left
+ <braunr> so yes, the idle one
+ <braunr> it's not bogus
+ <nlightnfotis> I thought m0 and g0 where the bootstrap m and g for the
+ scheduler.
+ <nlightnfotis> *correction: runtime_m0 and runtime_g0
+ <braunr> hm i got a bit fast
+ <braunr> G* g0; // goroutine with scheduling stack
+ <nlightnfotis> braunr: scheduling stack with stacksize = -1?
+ <nlightnfotis> unless it's not used as a parameter
+ <nlightnfotis> let me investigate that
+ <nlightnfotis> yeah now that I am seeing it, it might make sense, if it
+ using a default stack size, #defined as StackMin
+ <braunr> g0 looks like a placeholder
+ <braunr> i think it's used to reuse switching code when there is only one
+ goroutine involved
+ <braunr> e.g. when starting
+ <braunr> anyway i don't think we should waste too much time with it
+ <braunr> nlightnfotis: try to make a real 1:1 mapping
+ <braunr> that's something else i suggested last time
+ <nlightnfotis> braunr: ok. Where do you suspect the problem lies?
+ <braunr> context switching
+ <nlightnfotis> inside the goruntime?
+ <braunr> in glibc
+ <braunr> try to use runtime.LockOSThread
+ <braunr>
+ <braunr> nlightnfotis: is probably better
+ <nlightnfotis> what exactly do you mean by `use runtime.LockOSThread`?
+ LockOSThread locks the very first m and goroutine as the main threads
+ during process initialisation
+ <nlightnfotis> in proc.c line 565 or something
+ <braunr> i'm not sure it will help, because the problem is likely to occur
+ before even switching to the goroutine that locks its m, but worth trying
+ <braunr> 11:28 < braunr> nlightnfotis: is
+ probably better
+ <braunr> the first example is specific to GUIs that have requirements on
+ the main thread
+ <braunr> whereas i want every goroutine to run in its own thread
+ <nlightnfotis> I have also noticed that some context switching happens in
+ the goruntime even with a low number of goroutines and kernel threads
+ <braunr> that's expected
+ <braunr> goroutines must be viewed as works, and ms as worker threads
+ <braunr> everytime a goroutine sleeps, its m should be switching to useful
+ work
+ <braunr> nlightnfotis: i'd make prints (probably using mach_print) of
+ contexts when saved and restored
+ <braunr> and try to see if it makes any sense
+ <braunr> that's not simple to setup but not overly complicated either
+ <braunr> don't hesitate to ask for help
+ <nlightnfotis> from inside glibc, right?
+ <braunr> yes
+ <braunr> well
+ <braunr> no from go
+ <braunr> don't touch glibc from now
+ <braunr> put these prints near calls to makecontext/swapcontext
+ <braunr> and setcontext/getcontext
+ <braunr> wel
+ <braunr> you'll be using getcontext i think
+ <nlightnfotis> noted it all. I also have the gdb output you asked me for
+ <braunr> i don't see main
+ <nlightnfotis> some notes first: The main thread is the one with id 4, and
+ the output on the top is its backtrace.
+ <braunr> and main.main is run in thread 6
+ <nlightnfotis> Remember that main when it comes to go is in the file
+ go-main.c
+ <braunr> so main becomes runtime_MHeap_Scavenger
+ <nlightnfotis> yeah, main.main is the code of the program, (the one the
+ user wrote, not the runtime)
+ <nlightnfotis> yeah, it becomes a gc thread
+ <nlightnfotis> seeing as runtime_starttheworld reports that there is
+ already one gc thread
+ <braunr> and how much are __pthread_total and __pthread_num_threads for
+ that trace ?
+ <nlightnfotis> they were: __pthread_total = 2, and __pthread_num_threads =
+ 4
+ <braunr> can you paste the assertion again please, just to make sure
+ <nlightnfotis> a.out: ./pthread/pt-create.c:167: __pthread_create_internal:
+ Assertion `({ mach_port_t ktid = __mach_thread_self (); int ok =
+ thread->kernel_thread == ktid;
+ <nlightnfotis> __mach_port_deallocate ((__mach_task_self + 0), ktid); ok;
+ })' failed.
+ <braunr> btw, install the -dbg packages too
+ <nlightnfotis> dbg for which one? gccgo?
+ <braunr> libc0.3
+ <braunr> pthread/pt-create.c:167 is __pthread_sigstate (_pthread_self (),
+ 0, 0, &sigset, 0); here :/
+ <braunr> that assertion should be in __pthread_thread_start
+ <braunr> let's just say gdb is confused
+ <pinotree> braunr: apt-get source eglibc ; cd eglibc-* ; debian/rules patch
+ <braunr> pinotree: i have
+ <braunr> and that assertion can only trigger if __pthread_total is 1
+ <braunr> so let's say it just got to 2
+ <nlightnfotis> it does from very early on in process initialisation
+ <nlightnfotis> let me check this out again
+ <braunr> hm
+ <braunr> actually, both __pthread_total and __pthread_num_threads must be 1
+ <braunr> the context functions might be fine actually
+ <nlightnfotis> braunr: __pthread_num_threads = 2 right from the start of
+ the program
+ <nlightnfotis> 0x01da48ec is in mach_msg_trap
+ <braunr> something happened with libpthreads recently ..
+ <braunr> i can't even start iceweasel
+ <pinotree> braunr: what's the error?
+ <braunr> iceweasel: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70:
+ __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
+But not the [[open_issues/libpthread_dlopen]] issue?
+ <braunr> considering __pthread_threads is a global variable, this is tough
+ <braunr> i wonder if that's the issue with nlightnfotis's work
+ <braunr> wrong symbol resolution, leading libpthread to consider there is
+ only one thread running
+ <pinotree> try with LD_PRELOAD=/lib/i386-gnu/ iceweasel
+ <braunr> same
+ <braunr> maybe the switch to glibc 2.17
+ <braunr> this assertion is triggered by __pthread_self, assert
+ (__pthread_threads);
+ <braunr> __pthread_threads being the array of thread pointers
+ <braunr> so either corrupted (but we hardly changed anything ...) or wrong
+ resolution
+ <braunr> __pthread_num_threads includes the signal thread, __pthread_total
+ doesn't
+ <nlightnfotis> braunr: I recompiled with the libc debugging symbols and I
+ have new information
+ <nlightnfotis> the threads block at mach_msg_trap
+ <braunr> again, almost everything blocks there
+ <braunr> mach_msg is mach ipc, the way hurd system calls are implemented
+ <nlightnfotis> and the next calls (if it didn't block, from what I can see
+ from eip) are mach_reply_port and mach_thread_self
+ <braunr> please paste it
+ <nlightnfotis> yes give me 2 mins plz, brb
+ <braunr> pinotree: looks different for firefox
+ <braunr> it seems it calls pthread_key_create before pthread_create
+ <braunr> something our libpthread doesn't handle correctly
+ <nlightnfotis> braunr:
+ <pinotree> braunr: what do you mean?
+ <braunr> pinotree: i mean libpthread needs to be fixed so thread-specific
+ data can be set even without a call to pthread_create
+ <braunr> nlightnfotis: hum, we already knew it was blocking in a semaphore
+ <braunr> nlightnfotis: ok forget the other things i told you to test
+ <braunr> nlightnfotis: track __pthread_total and __pthread_num_threads
+ <braunr> add prints (again, with mach_print) to see when (and why) they
+ change and go back to 1
+ <pinotree> braunr: i see that pthread_key_create uses a mutex which in
+ turns needs _pthread_self(), but shouldn't at least one pthread_create be
+ done (directly by libc for the main thread)?
+ <braunr> pinotree: no :)
+ <braunr> well
+ <braunr> it should have been for the signal thread indeed
+ <braunr> and the signal thread exists
+ <pinotree> and the main thread?
+ <braunr> not the main, no
+ <pinotree> how so?
+ <braunr> a simple test program shows it does indeed work ..
+ <braunr> so this is again another problem in firefox too
+ <nlightnfotis> braunr: I don't think I understand this. I mean how can
+ pthread_total and __pthread_num_thread turn to 1, when , right before and
+ right after the crash they have numbers between 2, 3, and 4?
+ <braunr> how did you get their values "right before" the crash ?
+ <nlightnfotis> I have set a breakpoint to a printing function right before
+ the go statement
+ <nlightnfotis> (right before in this context, in the application code, not
+ the runtime code, but then again, I don't really think they are too far
+ each other)
+ <braunr> well, that's the mystery
+ <nlightnfotis> I am not challenging what you said, I will of course do,
+ just asking to understand some things
+ <braunr> they may either turn to 1, or there is some mess with symbol
+ resolution leading threads to see a value of 1
+ <nlightnfotis> *do it
+ <braunr> there*
+ <nlightnfotis> braunr: ping
+ <teythoon> just ask ;)
+ <nlightnfotis> teythoon: have you used mach_print?
+ <teythoon> no
+ <nlightnfotis> I have some questions about it
+ <teythoon> ask them
+ <nlightnfotis> I was told to use them inside go's runtime, to print the
+ values of __pthread_total and __pthread_num_threads. The thing is, these
+ values (I believe) are unknown to the runtime, they are only known to the
+ executable (linking time and later)
+ <teythoon> so? if the requested information is bound to a symbol that is
+ resolved at link time, you can print it from within the runtime
+ <teythoon> the same way any function from the libc is not known to the
+ executable until linking against it, but you can still "use" it in your
+ executable
+ <nlightnfotis> yeah, ok I understand that, but these are references that
+ are resolved at link time. The values I want to print are totally unknown
+ to the runtime (0 references to them)
+ <teythoon> if the value you are interested in is bound to the symbol
+ __pthread_total at link time, then you've got a reference you can use
+ <teythoon> doesn't printing __pthread_total work? did you try that?
+ <nlightnfotis> no, whenever I printed these values I did it from gdb. I am
+ trying to do what you suggested atm
+ <braunr> nlightnfotis: im here
+ <braunr> printing those values from libgo will tell us what value libgo
+ actually sees
+ <nlightnfotis> I am trying to use mach_print. Could you give me some
+ pointers on its usage (inside the goruntime?) (I have already read your
+ document here
+ and the example code)
+ <braunr> and symbol resolution may depend on where it's done from
+ <braunr> nlightnfotis: first, it only work with -dbg kernels
+ <braunr> so make sure you're running one
+ <braunr> actually, i'll write you a patch
+ <braunr> including a mach_printf function with argument parsing
+ <nlightnfotis> isn't it on by default? I read that on the document you are
+ discussing mach_printf
+ <nlightnfotis> ahh ok
+ <braunr> it's on by default on -dbg kernels
+ <braunr> i'll make a repository on darnassus too
+ <braunr> better store it there
+ <braunr> nlightnfotis:
+ <braunr> nlightnfotis: i suggest you implement mach_print with inline asm
+ statement in a C file, so that you don't need to alter the build system
+ configuration
+ <braunr> i'll make an example of that too
+ <nlightnfotis> braunr: that wasn't a problem. My only real problem atm is
+ that __atomic_t isn't recognised as a type, and I can not find the header
+ file for it on Hurd
+ <nlightnfotis> it was pt-internal.h in libpthread
+ <braunr> ah
+ <braunr> nlightnfotis: just in case, i updated the repository with an
+ inline assembly version
+ <braunr> let's see about __atomic_t
+ <braunr> sysdeps/i386/bits/pt-atomic.h:typedef __volatile int __atomic_t;
+ <braunr> nlightnfotis: just redeclare it as this locally
+ <braunr> nlightnfotis: ok ?
+ <nlightnfotis> I am working on it, because I still haven't found what
+ __atomic_t is typedefed from. Thinking of typedefing an int to it and see
+ how it goes
+ <nlightnfotis> braunr: found it just now: __volatile int
+ <braunr> "just now" ?
+ <braunr> 14:19 < braunr> sysdeps/i386/bits/pt-atomic.h:typedef __volatile
+ int __atomic_t;
+ <nlightnfotis> I was using cscope all this time
+ <braunr> why use cscope at all when i tell you where it is ?
+ <nlightnfotis> because I didn't notice it: your discussion was between
+ pino's and srs' and I wasn't tagged and thought it had something to do
+ with their discussion
+ <pinotree> (sorry)
+ <nlightnfotis> no it was my bad
+ <braunr> ok
+ <braunr> pinotree: there is indeed a special call to
+ __pthread_create_internal for the main thread
+ <pinotree> yeah
+ <pinotree> braunr: if there wouldn't be that libc→pthread bridge, things
+ like pthread_self() or so wouldn't work for the main thread
+ <braunr> pinotree: right
+ <pinotree> braunr: weird thing is that the error you got is usually a sign
+ that pthread is not linked in explicitly
+ <braunr> pinotree: yes
+ <braunr> pinotree: with firefox, gdb can't locate pthread symbols before a
+ call to a pthread function
+ <braunr> so yes, libpthread is loaded after main is called
+ <braunr> nlightnfotis: can you give me a quick procedure to build gcc with
+ go support from your repository, and then test a go program please ?
+ <braunr> to i can have a better look at it myself
+ <braunr> so*
+ <nlightnfotis> braunr: sure you want access to my go repo? If you already
+ have gcc repo add my github repo as a remote and checkout
+ fotisk/goruntime_hurd
+ <braunr> i have your github repo
+ <nlightnfotis> git checkout fotisk/goruntime_hurd (You may need to revert a
+ commit or two, because of my latest endeavour with mach_print
+ <nlightnfotis> braunr: check it out now, I reverted some messy commits for
+ you to rebuild
+ <braunr> nlightnfotis: i won't work on it right now, i'm building glibc to
+ check some things in libpthread
+ <braunr> since it seems to be the source of your problems and many others
+ <nlightnfotis> oh ok then. btw, it compiles ok, but when I try to compile
+ another program with gccgo collect2 cries about undefined references to
+ __pthread_num_threads and __pthread_total
+ <braunr> Oo
+ <braunr> another program ?
+ <nlightnfotis> braunr: will I get the same result if I slowly go through it
+ with gdb
+ <nlightnfotis> yep
+ <braunr> i don't understand
+ <braunr> what compiles ok, what fails ?
+ <nlightnfotis> gccgo compiles without errors (which is strange) but when I
+ use it to compile goroutine.go it fails with the errors I reported
+ <pinotree> (missing linking to pthread?)
+ <braunr> since when ?
+ <nlightnfotis> pinotree: perhaps braunr: since I made the changes with
+ mach_print
+ <nlightnfotis> pinotree: but what could be missing the link? GCC compiled
+ programs are getting linked automatically to the shared objects of the
+ headers they include right?
+ <nlightnfotis> (assuming it's not a huge program, only a tiny 10 liner for
+ instance)
+ <braunr> uh
+ <braunr> did you declare them as extern
+ <braunr> ?
+ <nlightnfotis> yes
+ <braunr> do you see -lpthread on the link line ?
+ <nlightnfotis> during gcc's compilation? I will have to rerun it again and
+ see.
+ <braunr> log the compilation output somewhere once
+ <braunr> nlightnfotis: why did you remove volatile from the definition of
+ __atomic_t ??
+ <nlightnfotis> just for testing purposes, because I thought that the GNU
+ version is volatile with no __ in front of it and that might cause some
+ issues.
+ <braunr> i don't understand
+ <nlightnfotis> it was just an experiment gone wrong
+ <braunr> nlightnfotis: keep volatile there
+ <nlightnfotis> just did
+ <nlightnfotis> braunr: there is -lpthread on some lines. For instance when
+ libtool is invoked.
+ <youpi> braunr: the pthread assertion usually happens when libpthread gets
+ loaded from a plugin, I guess mozilla got rid of libpthread in the main
+ application recently, simply
+ <pinotree> youpi: he said that the LD_PRELOAD trick (which used to
+ workaround the issue in older iceweasel) does not work, though
+ <youpi> ah? it does work for me
+ <pinotree> dunno then...
+ <braunr> youpi: aouch, ok
+ <braunr> nlightnfotis: what about the specific gcc invocation that fails ?
+ <braunr> pinotree: /lib/i386-gnu/ ERROR: cannot open
+ `/lib/i386-gnu/' (No such file or directory)
+ <braunr> trying with a working path this time
+ <braunr> better
+ <pinotree> sorry, i typed it by hand :p
+ <braunr> Segmentation fault
+ <braunr> but no assertion
+ <nlightnfotis> braunr: gccgo hello.go
+ <braunr> nlightnfotis: ?
+ <pinotree> <braunr> nlightnfotis: what about the specific gcc invocation
+ that fails ?
+ <braunr> nlightnfotis: i'm asking if -lpthread is present when you have
+ these undefined reference errors
+ <nlightnfotis> it is. it seems so
+ <nlightnfotis> I wrote above that it is present when libtool is called
+ <nlightnfotis> I don't know what libtool is doing sadly
+ <braunr> you said some lines
+ <nlightnfotis> but I from what I've seen I believe it does some kind of
+ linking
+ <braunr> paste it somewhere please
+ <nlightnfotis> yeah it doesn't fail though
+ <braunr> that's far too vague ...
+ <braunr> it doesn't fail ?
+ <nlightnfotis> give me a second
+ <braunr> i thought it did
+ <nlightnfotis> no it doesn't
+ <braunr> 14:53 < nlightnfotis> gccgo compiles without errors (which is
+ strange) but when I use it to compile goroutine.go it fails with the
+ errors I reported
+ <nlightnfotis> yeah gccgo compiles.
+ <nlightnfotis> when I use the compiler, it fails
+ <braunr> so it fails running
+ <braunr> is gccgo built with -lpthread itself ?
+ <nlightnfotis>
+ <nlightnfotis> check it out
+ <nlightnfotis> I think it does, but I would take an extra opinion
+ <nlightnfotis> line 782
+ <nlightnfotis> and 784
+ <braunr> (are you building as root ?)
+ <nlightnfotis> yes. for now
+ <pinotree> baaad :p
+ <nlightnfotis> I never had any particular problems...except that one time
+ that I rm -rf the source tree :P
+ <nlightnfotis> I know it's bad d/w
+ <nlightnfotis> braunr: I found something interesting (I don't know if it's
+ expected or not; probably not): If I set GOMAXPROCS to 2, and run the
+ goroutine program, it seems to be running for a while (with the
+ goroutines!) and then it segfaults. Will look more into it
+ <braunr> it's interesting, yes
+ <braunr> nlightnfotis: have you tried the preload trick too ?
+ <nlightnfotis> ldpreload? no. Could you tell me how to do it? export
+ LDPRELOAD and a path to libpthread?
+ <braunr> nlightnfotis: LD_PRELOAD=/lib/i386-gnu/ ...
+ <nlightnfotis> braunr: it also produces a very different backtrace. This
+ one heavily involves mig functions
+ <tschwinge> braunr, nlightnfotis: Thanks for working together, and sorry
+ for my lack of time.
+ <braunr> nlightnfotis: paste please
+ <nlightnfotis> tschwinge, Hello. It's ok, I am sorry for not showing good
+ amounts of progress from my part.
+ <nlightnfotis> braunr:
+ <braunr> nlightnfotis: thread apply all bt full please
+ <nlightnfotis> braunr:
+ <braunr> looks like an infinite loop of
+ __mach_port_mod_refs/__mig_dealloc_reply_port
+ <braunr> ...
+ <nlightnfotis> yes that's what I got from it too. Keep in mind these
+ results are with GOMAXPROCS=2 and they result in segmentation fault
+ <nlightnfotis> and I also can not understand the corrupted stack at the
+ beginning of the backtrace
+ <braunr> no please
+ <nlightnfotis> ?
+ <braunr> test LD_PRELOAD=/lib/i386-gnu/ without
+ <nlightnfotis> braunr: LD_PRELOAD without GOMAXPROCS results in the usual
+ assertion failure and abortion of execution after it
+ <braunr> nlightnfotis: ok
+ <braunr> nlightnfotis: im sorry, i thought you couldn't launch a test since
+ you added mach_print
+ <nlightnfotis> I am not using mach_print, I couldn't fix the issue with the
+ references and thought I was losing time, so I went back to debugging
+ with gdb until I can't get anything more out of it
+ <nlightnfotis> braunr: should I focuse on mach_print? Will it produce very
+ different results than gdb?
+ <nlightnfotis> *focus
+ <nlightnfotis> (btw I didn't delete mach print or anything, it's still
+ there, in another branch)
+ <nlightnfotis> braunr: Now I stepped through the program in gdb, and got
+ something really really weird. Some close to a full execution
+ <nlightnfotis> Number of gorountines and machine threads according to
+ runtime was 3, __pthread_num_threads was 4
+ <nlightnfotis> it did get SIGILL (illegal instruction some times though)
+ <nlightnfotis> and it exited with code 02
+ <braunr> uh
+ <braunr> nlightnfotis: try with mach_print yes, it will show the values
+ from the real execution context, and be as close as what we can get
+ <braunr> i'm not sure about how gdb finds the values
+ <nlightnfotis> braunr: ok, will spend the rest of the day to find a way to
+ make mach_print and the other values work. Did you see my last messages,
+ with the goroutines that worked under gdb?
+ <braunr> yes
+ <nlightnfotis> it seemed to run. Didn't get the expected output, but also
+ didn't get any errors other than illegal instruction either
+ <nlightnfotis> braunr: I still have not found an easy way to do what you
+ asked me to from go's runtime. Would it be ok if I do it from inside
+ libpthread?
+ <braunr> nlightnfotis: do what ?
+ <nlightnfotis> print the values of __pthread_total and
+ __pthread_num_threads with mach_print.
+ <braunr> how ?
+ <braunr> oh wait
+ <braunr> well yes ofc, they're not exported :/
+ <braunr> nlightnfotis: have you been able to use mach_print ?
+ <nlightnfotis> braunr: not really because of the problems I shared
+ earlier. I can try to use with in-gcc structures if you want me to, it's
+ nothing hard to do
+ <nlightnfotis> actually I will. Hang on
+ <braunr> proceed with debugging inside libpthread instead
+ <braunr> using mach_print to avoid deadlocks this time
+ <braunr> (mach_print was purposely built for debugging such low level code
+ parts)
+ <nlightnfotis> ok, I will patch this, but can I build it tomorrow?
+ <braunr> yes
+ <braunr> just keep us informed
+ <nlightnfotis> ok, thanks, and sorry for everything I have done. I want you
+ to know that I really appreciate that you are helping me.
+ <braunr> remember: the goal here is to understand why __pthread_total and
+ __pthread_num_threads have inconsistent values
+ <nlightnfotis> braunr: whenever you see it, mach_print works as expected
+ inside gcc.
+# IRC, freenode, #hurd, 2013-09-03
+ <nlightnfotis> braunr: I have made the changes I want to glibc. After I
+ build it, how do I install it? make install or is it more involved?
+ <braunr> nlightnfotis: use LD_LIBRARY_PATH
+ <braunr> never install an experimental glibc unless you have backups or are
+ certain of what you're doing
+ <braunr> nlightnfotis: i didn't understand what you meant about mach_print
+ yesterday
+ <nlightnfotis> it works in gcc.
+ <braunr> what do you mean "in gcc" ?
+ <braunr> why would you put mach_print in gcc ?
+ <braunr> we want it in go programs ..
+ <nlightnfotis> yes, I understand it. gcc was the fastest way to test it's
+ usage at that moment (for me) and I just wanted to confirm it works. I
+ only had to change its signature to const char * because gcc wouldn't
+ accept it otherwise
+ <braunr> doesn't my example include const ?
+ <braunr> nlightnfotis: why did you rebuild glibc ?
+ <nlightnfotis> braunr: I have not started yet, will do now, to apply the
+ changes to libpthread
+ <braunr> you mean add the print calls there ?
+ <nlightnfotis> yes
+ <braunr> ok
+ <braunr> use debian/rules build, interrupt when you see gcc invocations
+ <braunr> then switch to the build directory (hurd-libc-i386 iirc), and make
+ others
+ <braunr> nlightnfotis: did you send me the instructions to build and test
+ your work ?
+ <braunr> so i can reproduce these weird threading problems at my side
+ <nlightnfotis> braunr: sorry, I was in the toilet, where would you like me
+ to send the instructions?
+ <braunr> nlightnfotis: i should be fine i guess, let's check here
+ <braunr> nlightnfotis: i simply used configure
+ --enable-languages=c,c++,go,lto
+ <braunr> and i'll see how it goes
+ <nlightnfotis> I configure with --enable-languages=go (it automatically
+ builds c and c++ for that as go depends on them), --disable-bootstrap,
+ and use a custom prefix to install at a custom location
+ <braunr> yes
+ <braunr> ok
+ <braunr> nlightnfotis: how long does it take you ?
+ <nlightnfotis> complete non-bootstrap build about 45 minutes. With a build
+ tree ready and only simple changes, about 2-3 minutes
+ <nlightnfotis> braunr: In an hour I will go offline for 2-3 hours, I am
+ gonna move back to my other home in the other city. It won't take long,
+ the whole process will be about 4 hours, and I will compensate for the
+ time lost by staying up late up until 3 o clock in the morning
+ <braunr> i'd prefer you didn't "compensate"
+ <nlightnfotis> ?
+ <braunr> work if you want to
+ <braunr> noone if forcing you to work late at night for gsoc, unless you
+ want to
+ <nlightnfotis> no, I do it because I want to. I **really** really want to
+ succeed, and time is off the essence for me at this point
+ <braunr> then ok
+ <braunr> nlok i have a gccgo compiler
+ <pinotree> nlok?
+ <braunr> nl being nlightnfotis but he's gone
+ <pinotree> oh
+ * pinotree was trying to parse that as "now" or "look" or the like
+ <nlightnfotis> braunr: 08:19:56< braunr> use debian/rules build, interrupt
+ when you see gcc invocations: Are gcc invocations related to
+ i486-gnu-gcc-4.7?
+ <nlightnfotis> nvm I'm good now :)
+ <gnu_srs> of course not, that's only for compiling applications using the
+ newly built libc
+ <nlightnfotis> gnu_srs: I didn't exactly understand what you said? Care to
+ elaborate? which one is for compiling applications using the newly build
+ libc? -486-gnu-gcc-4.7?
+ <gnu_srs> when you see gcc ... you know is built, and
+ that is sufficient to use it.
+ <gnu_srs> with LD_PRELOAD or LD_LIBRARY_PATH (after cding and building
+ others)
+ <nlightnfotis> gnu_srs: thanks for the tip :)
+ <gnu_srs> :-D
+ <nlightnfotis> is anyone else getting glibc build problems? (from apt-get
+ source glibc, at cxa-finalize.c)?
+ <gnu_srs> apt-get source eglibc; apt-get build-dep eglibc (as root);
+ dpkg-buildpackage -b ...
+ <braunr> nlightnfotis: just debian/rules build
+ <braunr> to start the glibc build
+ <nlightnfotis> braunr: oh I have now, it's building without issues so far
+ <braunr> when you see gcc processes, it means the build process has
+ switched from configuring to making
+ <braunr> then interrupt (ctrl-c)
+ <braunr> cd build-tree/hurd-i386-libc
+ <braunr> make others
+ <braunr> or make lib others
+ <braunr> lib is glibc, others is some addons which include our libpthread
+ <nlightnfotis> thanks for the tip braunr.
+ <nlightnfotis> braunr: I have managed to get a working version of glibc and
+ libpthread with mach_print working. I have also run 2 test programs and
+ it works as expected. Will continue researching tomorrow if that's ok
+ with you, I am too tired to keep on now.
+ <nlightnfotis> for the record compilation of glibc right from the start was
+ about 1 hour and 20 - 30 minutes
+# IRC, freenode, #hurd, 2013-09-04
+ <braunr> i've taken a deeper look at this assertion failure
+ <braunr> and ...
+ <braunr> it has nothing to do with pthread_create
+ <braunr> i assumed it was the one in sysdeps/mach/pt-thread-start.c
+ <nlightnfotis> pthread_self ()?
+ <braunr> but it's actually from sysdeps/mach/hurd/pt-sysdep.h, in
+ _pthread_self()
+ <braunr> and looking there :
+ <braunr> thread = *(struct __pthread **)__hurd_threadvar_location
+ <braunr> so simply put, context switching doesn't fix up thread specific
+ data ...
+ <braunr> it's that simple
+ <nlightnfotis> wow
+ <nlightnfotis> today I was running programs all day long with mach_print on
+ to print __pthread_total and __pthread_num_threads to see when both
+ become 1 and couldn't find anything
+ <nlightnfotis> I was nearly desperate. You just made my day! :)
+ <braunr> now the problem is
+ <braunr> thread specific data is highly dependent on the stack
+ <braunr> it's illegal to make a thread switch stack and expect it to keep
+ working on the hurd
+ <nlightnfotis> unless split stack is activated?
+ <nlightnfotis> no wait
+ <braunr> split stack is completely unsupported on the hurd
+ <teythoon> uh, why would that be?
+ <braunr> teythoon: about split stack ?
+ <teythoon> yes
+ <braunr> i'm not sure
+ <nlightnfotis> at least now we do know what the problem is and I can start
+ working on a solution.
+ <nlightnfotis> braunr: we should tell tschwinge and youpi about it.
+ <braunr> nlightnfotis: sure but
+ <braunr> nlightnfotis: you can also start looking at a workaround
+ <braunr> nlightnfotis: also, let's makre sure that's the reason first
+ <braunr> nlightnfotis: use mach_print to display the stack pointer when
+ switching
+ <braunr> nlightnfotis:
+ <braunr> " I believe runtime.LockOSThread() is necessary if you are
+ creating a library binding from C code which uses thread-local storage"
+ <braunr> oh, a paper about the go runtime scheduler
+ <braunr> let's have a look ..
+ <teythoon> braunr: have you seen the high level overview presented in that
+ blog post I once posted here?
+ <braunr> no
+ <nlightnfotis> braunr, just came back, and read the log. Which paper are
+ you reading? The one from columbia university?
+ <braunr> but i need to know about details here, specifically, if threads do
+ change stack
+ <braunr> nlightnfotis: yes
+ <teythoon> braunr: ok
+ <braunr> this could be caused either by true stack switching, or by "stack
+ segmentation" as implemented by go
+ <braunr> it is interesting that there are stack related members per
+ goroutine
+ <braunr> nlightnfotis: in particular, pthread_attr_setstacksize() doesn't
+ work on the hurd
+ <nlightnfotis> <braunr> it is interesting that there are stack related
+ members per goroutine -> I think that's go's policy. All goroutines run
+ on a shared address space (that is the kernel thread's address space)
+ <braunr> nlightnfotis: that's obvious
+ <braunr> and not the problem
+ <braunr> and yes, it's "stack segmentation"
+ <braunr> and on linux, and probably other archs, switching stack may be
+ perfectly legit
+ <braunr> on the hurd, we still have threadvars
+ <braunr> which are the hurd specific thread local storage mechanism
+ <braunr> it means 1/ all stacks in a process must have the same size
+ <braunr> 2/ stack size must be a power of two
+ <braunr> 3/ threads can't switch stack
+ <braunr> this hardly prevents goroutines from being run by just any thread
+ <braunr> i see there already hard hurd specific changes about stack
+ handling
+ <nlightnfotis> so we should only make changes to the specific gccgo
+ scheduler as a workaround under the Hurd right?
+ <braunr> i don't know
+ <braunr> this might also push the switch to tls
+ <nlightnfotis> this sounds better as a long term fix
+ <nlightnfotis> but it must also involve a great amount of work, right?
+ <braunr> most of it has already been done
+ <braunr> by youpi and tschwinge
+ <nlightnfotis> with the changes to tls early in the summer?
+ <braunr> maybe
+ <braunr> 14:36 < braunr> nlightnfotis: also, let's makre sure that's the
+ reason first
+ <braunr> 14:36 < braunr> nlightnfotis: use mach_print to display the stack
+ pointer when switching
+ <braunr> check what goes wrong with the stack
+ <braunr> then we'll see
+ <braunr> as a very simple workaround, i expect locking g's on m's to be a
+ good first step
+ <nlightnfotis> braunr: noted everything. that's my work for tonight. I
+ expect myself to stay up late like yesterday and have this all figured
+ out by tomorrow.
+ <braunr> nlightnfotis: why not now ?
+ <nlightnfotis> I am starting from now, but I expect myself to stop about 6
+ o clock here (2 hours) because I have an appointment with a doctor.
+ <nlightnfotis> and keep on when I come back home
+ <braunr> well adding a few printfs to track the stack should be doable
+ before 2 hours
+ <nlightnfotis> braunr: I am doing it now. Will report as soon as I have
+ results :)
+ <nlightnfotis> braunr: have I messed up with the way I read esp's value?
+ <braunr> nlightnfotis: +unsigned
+ <braunr> nlightnfotis: using gdb :
+ <braunr> (gdb) info registers
+ <braunr> esp 0x203ff7c0 0x203ff7c0
+ <braunr> (gdb) print thread->stackaddr
+ <braunr> $2 = (void *) 0x2000000
+ <nlightnfotis> oh yes, I know about gdb, I thought you wanted me to use
+ mach_print
+ <braunr> nlightnfotis: yes
+ <braunr> this is just my own attempt
+ <braunr> and it does show the stack pointer is completely outside the
+ thread stack
+ <braunr> nlightnfotis: in your code, i suggest using
+ __builtin_frame_address()
+ <braunr> well __builtin_frame_address(0)
+ <braunr> see
+ <braunr> it's not exactly the stack pointer but close enough, unless of
+ course the stack is changed in the middle of the function
+ <nlightnfotis> I see. I am gonna try one more time with esp the way I
+ worked it and if it fails to work, I am gonna use return address
+ <braunr> nlightnfotis: be very careful about signed/unsigned and type
+ widths
+ <braunr> not return address, frame address
+ <braunr> return address is code, frame address is data (stack)
+ <nlightnfotis> ah, I see, thanks for the correction.
+ <braunr> youpi: not sure you catched it earlier, the problem fotis has been
+ having with goroutines is about threadvars
+ <braunr> simply put, threads use setcontext functions to save/restore
+ goroutines state, which make them switch stack, rendering the location of
+ threadvars invalid, and making _pthread_self() choke
+# IRC, freenode, #hurd, 2013-09-05
+ <nlightnfotis> I am having very weird behavior with my code, something that
+ I can not explain and seems likely to be a bug, could someone else take a
+ look?
+ <nlightnfotis> pinotree are you available at the moment to take a look at
+ something?
+ <pinotree> nlightnfotis: dont ask to ask, just ask
+ <nlightnfotis> I have made some modifications to pthread_self as also
+ suggested by braunr to see if the stack pointer is within the bounds of
+ the frame address after context switching. I can get the values of both
+ esp and frame_address to be shown before the context switch, but I can
+ only get the value of esp to be shown after the context switch, and it
+ always results to the program getting killed
+ <nlightnfotis>
+ <nlightnfotis> thing is a dummy print value I have right after the code
+ that was supposed to print the frame_address after the context switching
+ is executing without any issues.
+ <pinotree> oh assembler... cannot help, sorry :/
+ <nlightnfotis> oh no, I am not asking for assembler help, that part works
+ quite alright. I am asking why from the 4 identical pieces of code that
+ print debugging values the last one doesn't work. I am on it all day, and
+ still have not found an answer
+ <braunr> nlightnfotis: i can
+ <nlightnfotis> hello braunr,
+ <braunr> nlightnfotis: do you have a backtrace ?
+ <braunr> uh
+ <nlightnfotis> nope, it crashes right after I execute something. Let me
+ compile glibc once again and see if a fix I attempted works
+ <braunr> malloc and free use locks
+ <braunr> so they probably use _pthread_self
+ <braunr> don't use them
+ <braunr> for debugging, a simple statically allocated buffer on the stack
+ will do
+ <braunr> nlightnfotis: so ?
+ <nlightnfotis> Ι got past my original problem, but now I am trying to get
+ past the sigkills that kill the program at the beginning
+ <nlightnfotis> i remember not having this problem, so I am compiling my
+ master branch to see if it is reproducible. If it is, it means something
+ is very wrong. If it's not, it means I screwed up somewhere
+ <braunr> i don't understand, how do you know if you get past the problem if
+ you still have trouble reaching that code ?
+ <nlightnfotis> braunr: I fixed all my problems now. I can see that both esp
+ and the frame_address are the same after context switching though?
+ <braunr> always ?
+ <braunr> for all goroutines ?
+ <nlightnfotis> for all kernel threads, not go routines. We are in
+ libpthread
+ <braunr> if they're the same after a context switch, it usually means the
+ scheduler didn't switch
+ <braunr> well obviously
+ <braunr> but what i asked you was to trace calls to setcontext functions
+ <nlightnfotis> I will run some tests again. May I show you my code to see
+ if there is anything wrong with it?
+ <braunr> what address do you have ?
+ <braunr> not yet
+ <braunr> i'm not sure you understand what i want to check
+ <braunr> do you see how threadvars work basically ?
+ <nlightnfotis> I think so yes, they keep in the stack the local variables
+ of a thread right?
+ <nlightnfotis> and the globals
+ <nlightnfotis> or
+ <nlightnfotis> wait a minute...
+ <braunr> yes but do you see how the thread specific data are fetched ?
+ <nlightnfotis> with __hurd_threadvar_location_from_sp?
+ <braunr> yes but "basically", what does it do ?
+ <nlightnfotis> it get's a stack pointer as a parameter, and returns the
+ location of that specific data based on that stack pointer, right?
+ <braunr> and how ?
+ <nlightnfotis> I believe it must compare the base value of the stack and
+ the value of the end of the stack, and if the results are consistent, it
+ returns a pointer to the data?
+ <braunr> and how does it determine the start and end of the stack ?
+ <nlightnfotis> stack_pointer must be pointing at the base of the
+ stack. That + stack_size must be the stack limit I guess.
+ <braunr> so you're saying the caller of __hurd_threadvar_location_from_sp
+ knows the stack base ?
+ <nlightnfotis> I am not so sure I understand this question.
+ <braunr> i want to know if you understand how threadvars work
+ <braunr> apparently you don't
+ <braunr> the caller only has its current stack pointer
+ <braunr> which does *not* point to the stack base
+ <braunr> threadvars work by assuming a *fixed* stack size, power of two,
+ aligned (obviously)
+ <braunr> in our case, 2MiB (except in hurd servers where a kludge reduces
+ that to 64k)
+ <braunr> this is why stack size can't be changed
+ <braunr> this is also why the stack pointer can't ever point outside the
+ initial stack
+ <braunr> i want you to make sure go violates this last assumption
+ <braunr> so 1/ show the initial stack boundaries of your threads, then show
+ that, after loading a goroutine, the stack pointer is outside
+ <braunr> which is what, if i'm right, triggers the assertion
+ <braunr> ask if there is anything confusing
+ <braunr> this is important, it should already have been done
+ <nlightnfotis> ok, I noted it all, I am starting to work on it right now. I
+ only have one question. My results, the ones with the stack pointer and
+ the frame address, are expected or unexpected?
+ <braunr> i don't know
+ <braunr> show me the code again please
+ <braunr> and explain your intent
+ <nlightnfotis>
+ <nlightnfotis> At first I print the value of esp and the frame_address
+ before the context switching and after the context switching.
+ <nlightnfotis> The different variables were introduced as part of a test to
+ see if my results were consistent,
+ <braunr> what context switch ?
+ <nlightnfotis> in hurd_threadvar_location
+ <braunr> what makes you think this is a context switch ?
+ <nlightnfotis> in threadvar.h, it calls __hurd_threadvar_location_from_sp.
+ <nlightnfotis> the full path for it is glibc/hurd/hurd/threadvar.h
+ <braunr> i don't see how giving me the path will explain why it's a context
+ switch
+ <braunr> and i can tell you right away it's not
+ <braunr> hurd_threadvar_location is basically a lookup returning the
+ address of the thread specific data
+ <nlightnfotis> wait a minute...does this mean that
+ hurd_threadvar_location_from_sp is also a lookup function for the same
+ reason
+ <nlightnfotis> ?
+ <braunr> yes
+ <braunr> isn't the name meaningful enough ?
+ <braunr> "location of the threadvars from stack pointer"
+ <nlightnfotis> I guess I made wrong deductions from when you originally
+ shared your findings...
+ <nlightnfotis> <braunr> thread = *(struct __pthread
+ **)__hurd_threadvar_location (_HURD_THREADVAR_THREAD);
+ <nlightnfotis> <braunr> so simply put, context switching doesn't fix up
+ thread specific data ...
+ <nlightnfotis> I thought that hurd_threadvar_location was doing the context
+ switching
+ <braunr> nlightnfotis: by context switching, i mean setcontext functions
+ <nlightnfotis> braunr: You mean the one in sysdeps/mach/hurd/i386?
+ <braunr> yes
+ <braunr> but
+ <braunr> do you understand what i want you to check now ?
+ <nlightnfotis> I think I got this time: Let me explain it:
+ <nlightnfotis> You suggested that stack sizes are fixed. That is the main
+ reason that the stack pointer should not be able to point outside of it.
+ <braunr> no
+ <braunr> locating threadvars is done by applying a mask, computed from the
+ stack size, on the stack pointer, to determine its base
+ <nlightnfotis> yeah, what __hurd_threadvar_location_from_sp is doing
+ <braunr> if size is a power of two, size - 1 is a mask that, if
+ complemented, aligns the address
+ <braunr> yes
+ <braunr> so, threadvars expect the stack pointer to always point to the
+ initial stack
+ <nlightnfotis> and we wanna prove that go violates this rule right? That
+ the stack pointer is not pointing at the initial stack
+ <braunr> yes
diff --git a/community/gsoc/project_ideas/download_backends.mdwn b/community/gsoc/project_ideas/download_backends.mdwn
index f794e814..c0bdc5b2 100644
--- a/community/gsoc/project_ideas/download_backends.mdwn
+++ b/community/gsoc/project_ideas/download_backends.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
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
[[!meta title="Use Internet Protocol Translators (ftpfs etc.) as Backends for Other Programs"]]
@@ -19,8 +19,9 @@ Download protocols like FTP, HTTP, BitTorrent etc. are very good candidates for
this kind of modularization: a program could simply use the download
functionality by accessing FTP, HTTP etc. translators.
-There is already an ftpfs translator in the Hurd tree, as well as an [httpfs
-translator on hurdextras](; however,
+There is already an [[hurd/translator/ftpfs]] translator in the Hurd tree, as
+well as an [[hurd/translator/httpfs]] on
+[hurdextras](; however,
these are only suitable for very simple use cases: they just provide the actual
file contents downloaded from the URL, but no additional status information
that are necessary for interactive use. (Progress indication, error codes, HTTP
diff --git a/community/gsoc/project_ideas/mtab/discussion.mdwn b/community/gsoc/project_ideas/mtab/discussion.mdwn
index 0e322c11..716fb492 100644
--- a/community/gsoc/project_ideas/mtab/discussion.mdwn
+++ b/community/gsoc/project_ideas/mtab/discussion.mdwn
@@ -106,7 +106,7 @@ License|/fdl]]."]]"""]]
# IRC, freenode, #hurd, 2013-06-25
-In context of [[microkernel/mach/mig/documentation/structured_data]].
+In context of [[open_issues/mig_portable_rpc_declarations]].
<teythoon> should I go for an iterator like interface instead?
<teythoon> btw, what's the expected roundtrip time?
@@ -905,3 +905,1168 @@ In context of [[microkernel/mach/mig/documentation/structured_data]].
<teythoon> ah, i think so
<braunr> then you don't need to do it again
<teythoon> right, I overlooked that
+## IRC, freenode, #hurd, 2013-07-12
+ <teythoon> recursively traversing all translators from / turns out to be
+ more dangerous than I expected
+ <teythoon> ... if done by a translator bound somewhere below /...
+ <teythoon> my interpretation is that the mtab translator tries to talk to
+ itself and deadlocks
+ <teythoon> (and as a side effect the whole system kinda just stops...)
+## IRC, freenode, #hurd, 2013-07-15
+ <youpi> teythoon: did you discuss with braunr about returning port vs path
+ in fsys_get_children?
+ <teythoon> youpi: we did
+ <teythoon> as I wrote I looked at the getcwd source you pointed me at
+ <teythoon> and I started to code up something similar
+ <teythoon> but as far as I can see there's no way to tell from a port
+ referencing a file the directory this file is located in
+ <youpi> ah, right, there was a [0] mail
+ <youpi> teythoon: because it doesn't have a "..", right
+ <teythoon> about Neals concerns, he's right about not covering passive
+ translators very well
+ <teythoon> but the solution he proposed was similar to what I tried to do
+ first
+ <youpi> I don't like half-covering passive translators at all, to be honest
+ :)
+ <youpi> either covering them completely, or not at all, would be fine
+ <teythoon> and then braunr convinced me that the "recursive" approach is
+ more elegant and hurdish, and I came to agree with him
+ <teythoon> youpi: one could scan the filesystem at translator startup and
+ populate the list
+ <youpi> by "Neal's solution", you mean an mtab registry?
+ <teythoon> yes
+ <braunr> so, let's see what linux does when renaming parent directories
+ <teythoon> mount points you mean?
+ <youpi> teythoon: browsing the whole filesystem just to find passive
+ translators is costly
+ <youpi> teythoon, braunr: and that won't prevent the user from unexpectedly
+ starting other translators at will
+ <braunr> scary
+ <teythoon> youpi: but that requires the privilege to open the device
+ <youpi> the fact that a passive translator is set is nothing more than a
+ user having the intent of starting a translator
+ <braunr> linux retains the original path in the mount table
+ <youpi> heh
+ <teythoon> youpi: any unprivileged user can trigger a translator startup
+ <youpi> sure, but root can do that too
+ <youpi> and expect the system to behave nicely
+ <teythoon> but if I'm root and want to fsck something, I won't start
+ translators accessing the device just before that
+ <teythoon> but if there's a passive translator targetting the device,
+ someone else might do that
+ <youpi> root does not always completely control what he's doing
+ <youpi> linux for instance does prevent from mounting a filesystem being
+ checked
+ <teythoon> but still, including passive translators in the list would at
+ least prevent anyone starting an translator by accident, isn't that worth
+ doing then?
+ <youpi> if there's a way to prevent root too, that's better than having a
+ half-support for something which we don't necessarily really want
+ <youpi> (i.e. an exclusive lock on the underlying device)
+ <teythoon> right, that would also do the trick
+ <teythoon> btw, some programs or scripts seem to hardcode /proc/mounts and
+ procfs and I cannot bind a translator to /proc/mounts since it is
+ read-only and the node does not exist
+ <kilobug> IMHO automatically starting translators is a generic feature, and
+ passive translator is just a specific instance of it; but we could very
+ well have, like an "autofs" that automatically start translators in tar
+ archives and iso images, allowing to cd into any tar/iso on the system;
+ implementing such things is part of the Hurd flexibility, the "core
+ system" shouldn't be too aware on how translators are started
+ <youpi> so in the end, storing where the active translator was started
+ first seems okayish according to what linux has been exposing for decades
+ <youpi> kilobug: indeed
+ <teythoon> it could serve a mounts with a passive translator by default, or
+ a link to /run/mtab, or an simple file so we could bind a translator to
+ that node
+ <youpi> I'd tend to think that /proc/mounts should be a passive translator
+ and /run/mtab / /etc/mtab a symlink to it
+ <youpi> not being to choose the translator is a concern however
+ <teythoon> ok, I'll look into that
+ <youpi> it could be an empty file, and people be able to set a translator
+ on it
+ <teythoon> if it had a passive translator, people still could bind their
+ own translator to it later on, right?
+ <teythoon> afaics the issue currently is mostly, that there is no mounts
+ node and it is not possible to create one
+ <youpi> right
+ <teythoon> cool
+ <youpi> so with the actual path, you can even check for caller's permission
+ to read the path
+ <youpi> i.e. not provide any more information than the user would be able
+ to get from browsing by hand
+ <teythoon> sure, that concern of Neil's is easy to address
+ <youpi> I'm not so much concerned by stale paths being shown in mtab
+ <youpi> the worst that can happen is a user not being able to umount the
+ path
+ <youpi> but he can settrans -g it
+ <youpi> (which he can't on linux ;) )
+ <teythoon> yes, and the device information is still valid
+ <youpi> yes
+ <braunr> despite the parent dir being renamed, linux is still able to
+ umount the new path
+ <teythoon> and so is our current umount
+ <braunr> good
+ <teythoon> (if one uses the mount point as argument)
+ <braunr> what's the current plan concerning /proc/mounts ?
+ <teythoon> serving a node with a passive translator record
+ <braunr> ?
+ <teythoon> so that /hurd/mtab / is started on access
+ <braunr> i mean, still planning on using the recursive approach instead of
+ a registry ?
+ <teythoon> ah
+ <teythoon> I do not feel confident enough to decide this, but I agree with
+ you, it feels elegant
+ <teythoon> and it works :)
+ <teythoon> modulo the translator deadlocking if it talks to itself, any
+ thoughts on that?
+ <youpi> it is a non-threaded translator I guess?
+ <teythoon> currently yes
+ <youpi> making it threaded should fix the issue
+ <teythoon> I tried to make the mtab translator multithreaded but that
+ didn't help
+ <youpi> that's odd
+ <teythoon> maybe I did it wrong
+ <braunr> i don't find it surprising
+ <braunr> well, not that surprising :p
+ <braunr> on what lock does it block ?
+ <teythoon> as far as i can see the only difference of hello and hellot-mt
+ is that it uses a different dispatcher and has lot's of locking, right?
+ <teythoon> braunr: I'm not sure, partly because that wrecked havoc on the
+ whole system
+ <teythoon> it just freezes
+ <teythoon> but it wasn't permanent. once i let it running and it recovered
+ <braunr> consider using a subhurd
+ <teythoon> ah right, I ment to set up one anyway, but my first attempts
+ were not successful, not sure why
+ <teythoon> anyway, is there a way to prevent this in the first place?
+ <teythoon> if one could compare ports that'd be helpful
+ <youpi> Mmm, did you try to simply compare the number?
+ <teythoon> with the bootstrap port I presume?
+ <youpi> Mmm, no, the send port and the receive port would be different
+ <youpi> no, with the receive port
+ <teythoon> ah
+ <braunr> comparing the numbers should work
+ <braunr> youpi: no they should be the same
+ <youpi> braunr: ah, then it should work yes
+ <braunr> that's why there are user ref counts
+ <youpi> ok
+ <braunr> only send-once rights have their own names
+ <teythoon> btw, I'll push my work to darnassus from now on,
+ e.g.;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip
+## [[open_issues/libnetfs_passive_translators]]
+## IRC, freenode, #hurd, 2013-07-16
+ <teythoon> which port is the receive port of a translator? I mean, how is
+ it called in the source, there is no port in sight named receive anywhere
+ I looked.
+ <braunr> teythoon: what is the "receive port of a translator" ?
+ <teythoon> braunr: we talked yesterday about preventing the mtab deadlock
+ by comparing ports
+ <teythoon> I asked which one to use for the comparison, youpi said the
+ receive port
+ <braunr> i'm not sure what he meant
+ <braunr> it could be the receive port used for the RPC
+ <braunr> but i don't think it's exported past mig stub code
+ <teythoon> weird, I just reread it. I asked if i should use the bootstrap
+ port, and he said receive port, but it might have been addressed to you?
+ <teythoon> you were talking about send and receive ports being singletons
+ or not
+ <teythoon> umm
+ <braunr> no i answered him
+ <braunr> he was wondering if the receive port could actually be used for
+ comparison
+ <braunr> i said it can
+ <braunr> but still, i'm not sure what port
+ <braunr> if it's urgent, send him a mail
+ <teythoon> no, my pipeline is full of stuff I can do instead ;)
+ <braunr> :)
+## IRC, freenode, #hurd, 2013-07-17
+ <teythoon> braunr: btw, comparing ports solved the deadlock in the mtab
+ translator rather easily
+ <braunr> :)
+ <braunr> which port then ?
+ <teythoon> currently I'm stuck though, I'm not sure how to address Neals
+ concern wrt to access permission checks
+ <teythoon> I believe it's called control port
+ <braunr> ok
+ <teythoon> the one one gets from doing the handshake with the parent
+ <braunr> i thought it was the bootstrap port
+ <braunr> but i don't know the details so i may be wrong
+ <braunr> anyway
+ <teythoon> yes
+ <braunr> what is the permission problem again ?
+ <teythoon>
+ <braunr> well, you could perform a lookup on the stored path
+ <braunr> as if opening the node
+ <teythoon> if I look at any server implementation of a procedure from
+ fs.defs (say libtrivfs/file-chmod.c [bad example though, that looks wrong
+ to me]), there is permission checking being done
+ <teythoon> any server implementation of a procedure from fsys.defs lacks
+ permission checks, so I guess it's being done somewhere else
+ <braunr> i must say i'm a bit lost in this discussion
+ <braunr> i don't know :/
+ <braunr> can *you* sum up the permission problem please ?
+ <braunr> i mean here, now, in just a few words ?
+ <teythoon> ok, so I'm extending the fsys api with the get_children
+ procedure
+ <teythoon> that one should not return any children x/y if the user doing
+ the request has no read permissions on x
+ <braunr> really ?
+ <braunr> why so ?
+ <teythoon> the same way ls x would not reveal the existence of y
+ <braunr> i could also say unlike cat /proc/mounts
+ <braunr> i can see why we would want that
+ <braunr> i also can see why we could let this behaviour in place
+ <braunr> let's admit we do want it
+ <teythoon> true, but I thought this could easily be addressed
+ <braunr> what you could do is
+ <teythoon> now I'm not sure b/c I cannot even find the permission checking
+ code for any fsys_* function
+ <braunr> for each element in the list of child translators
+ <braunr> perform a lookup on the stored path on behalf of the user
+ <braunr> and add to the returned list if permission checks pass
+ <braunr> teythoon: note that i said lookup on the path, which is an fs
+ interface
+ <braunr> i assume there is no permission checking for the fsys interface
+ because it's done at the file (fs) level
+ <teythoon> i think so too, yes
+ <teythoon> sure, if I only knew who made the request in the first place
+ <teythoon> the file-* options have a convenient credential handle passed in
+ as first parameter
+ <teythoon> s/options/procedures/
+ <teythoon> surely the fsys-* procedures also have a means of retrieving
+ that information, I just don't know how
+ <braunr> mig magic
+ <braunr> teythoon: see file_t in hurd_types.defs
+ <braunr> there is the macro FILE_INTRAN which is defined in subdirectories
+ (or not)
+ <teythoon> ah, retrieving the control port requires permissions, and the
+ fsys-* operations then operate on the control port?
+ <braunr> see libdiskfs/fsmutations.h for example
+ <braunr> uh yes but that's for < braunr> i assume there is no permission
+ checking for the fsys interface because it's done at the file (fs) level
+ <braunr> i'm answering < teythoon> sure, if I only knew who made the
+ request in the first place
+ <braunr> teythoon: do we understand each other or is there still something
+ fuzzy ?
+ <teythoon> braunr: thanks for the pointers, I'll read up on that a bit
+ later
+ <braunr> teythoon: ok
+## IRC, freenode, #hurd, 2013-07-18
+ <teythoon> braunr: back to the permission checking problem for the
+ fsys_get_children interface
+ <teythoon> I can see how this could be easily implemented in the mtab
+ translator, it asks the translator for the list of children and then
+ checks if the user has permission to read the parent dir
+ <teythoon> but that is pointless, it has to be implemented in the
+ fsys_get_children server function
+ <braunr> yes
+ <braunr> why is it pointless ?
+ <teythoon> because one could circumvent the restriction by doing the
+ fsys_get_children call w/o the mtab translator
+ <braunr> uh no
+ <braunr> you got it wrong
+ <braunr> what i suggested is that fsys_get_children does it before
+ returning a list
+ <braunr> the problem is that the mtab translator has a different identity
+ from the users accessing it
+ <teythoon> yes, but I cannot see how to do this, b/c at this point I do not
+ have the user credentials
+ <braunr> get them
+ <teythoon> how?
+ <braunr> 16:14 < braunr> mig magic
+ <braunr> 16:15 < braunr> teythoon: see file_t in hurd_types.defs
+ <braunr> 16:16 < braunr> there is the macro FILE_INTRAN which is defined in
+ subdirectories (or not)
+ <braunr> 16:16 < braunr> see libdiskfs/fsmutations.h for example
+ <teythoon> i saw that
+ <braunr> is there a problem i don't see then ?
+ <braunr> i suppose you should define FSYS_INTRAN rather
+ <braunr> but the idea is the same
+ <teythoon> won't that change all the function signatures of the fsys-*
+ family?
+ <braunr> that's probably the only reason not to implement this feature
+ right now
+ <teythoon> then again, that change is probably easy and mechanic in nature,
+ might be an excuse to play around with coccinelle
+ <braunr> why not
+ <braunr> if you have the time
+ <teythoon> right, if this can be done, the mtab translator (if run as root)
+ could get credentials matching the users credentials to make that
+ request, right?
+ <braunr> i suppose
+ <braunr> i'm not sure it's easy to make servers do requests on behalf of
+ users on the hurd
+ <braunr> which makes me wonder if the mtab functionality shouldn't be
+ implemented in glibc eheheh ....
+ <braunr> but probably not
+ <teythoon> well, I'll try out the mig magic thing and see how painful it is
+ to fix everything ;)
+ <braunr> good luck
+ <braunr> honestly, i'm starting to think it's deviating too much from your
+ initial goal
+ <braunr> i'd be fine with a linux-like /proc/mounts
+ <braunr> with a TODO concerning permissions
+ <teythoon> ok, fine with me :)
+ <braunr> confirm it with the other mentors please
+ <braunr> we have to agree quickly on this
+ <teythoon> y?
+ <teythoon> braunr: I actually believe that the permission issue can be
+ addressed cleanly and unobstrusively
+ <teythoon> braunr: would you still be opposed to the get_children approach
+ if that is solved?
+ <teythoon> the filesystem is a tree and the translators "creating" that
+ tree are a more coarse version of that tree
+ <teythoon> having a method to traverse that tree seems natural to me
+ <braunr> teythoon: it is natural
+ <braunr> i'm just worried it's a bit too complicated, unnecessary, and
+ out-of-scope for the problem at hand
+ <braunr> (which is /proc/mounts, not to forget it)
+## IRC, freenode, #hurd, 2013-07-19
+ <teythoon> braunr: I think you could be a bit more optimistic and
+ supportive of the decentralized approach
+ <teythoon> I know the dark side has cookies and strong language and it's
+ mighty tempting
+ <teythoon> but both are bad for you :p
+## IRC, freenode, #hurd, 2013-07-22
+ <youpi> teythoon: AIUI, you should be able to run the mtab translator as
+ no-user (i.e. no uid)
+ <teythoon> youpi: yes, that works fine
+ <youpi> teythoon: so there is actually no need to define FSYS_INTRAN, doing
+ it by hand as you did is fine, right?
+ <youpi> (/me backlogs mails...)
+ <teythoon> youpi: yes, the main challenge was to figure out what mig does
+ and how the cpp is involved
+ <youpi> heh :)
+ <teythoon> my patch does exactly the same, but only for this one server
+ function
+ <teythoon> youpi: I'm confused by your mail, why are read permissions on
+ all path components necessary?
+ <braunr> teythoon: only execution normally
+ <youpi> teythoon: to avoid letting a user discover a translator running on
+ a hidden directory
+ <teythoon> braunr: exactly, and that is tested
+ <youpi> e.g. ~/home/foo is o+x, but o-r
+ <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU
+ <youpi> I don't want that to show up on /proc/mounts
+ <braunr> youpi: i don't understand either: why isn't execution permission
+ enough ?
+ <teythoon> youpi: but that requires testing for read on the *last*
+ component of the *dirname* of your translator, and that is tested
+ <youpi> let me take another example :)
+ <youpi> e.g. ~/home/foo/aZeRtYuyU is o+x, but o-r
+ <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU/foo
+ <youpi> ergl sorry, I meant this actually:
+ <teythoon> yes, that won't show up then in the mtab for users that are not
+ you and not root
+ <youpi> e.g. ~/home/foo is o+x, but o-r
+ <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU/foo
+ <teythoon> ah
+ <teythoon> hmm, good point
+ <braunr> ?
+ * braunr still confused
+ <teythoon> well, qwfpgjlu is the secret
+ <teythoon> and that is revealed by the fsys_get_children procedure
+ <braunr> then i didn't understand the description of the call right
+ <braunr> > + /* check_access performs the same permission check as is
+ normally
+ <braunr> > + done, i.e. it checks that all but the last path components
+ are
+ <braunr> > + executable by the requesting user and that the last
+ component is
+ <braunr> > + readable. */
+ <teythoon> braunr: youpi argues that this is not enough in this case
+ <braunr> from that, it looks ok to me
+ <youpi> the function and the documentation agree, yes
+ <youpi> but that's not what we want
+ <braunr> and that's where i fail to understand
+ <youpi> again, see my example
+ <braunr> i am
+ <braunr> 10:43 < youpi> e.g. ~/home/foo is o+x, but o-r
+ <braunr> ok
+ <youpi> so the user is not supposed to find out the secret
+ <braunr> then your example isn't enough to describe what's wron
+ <braunr> g
+ <youpi> checking read permission only on ~/home/foo/aZeRtYuyU will not
+ garantee that
+ <braunr> ah
+ <braunr> i thought foo was the last component
+ <youpi> no, that's why I changed my example
+ <braunr> hum
+ <braunr> 10:43 < youpi> e.g. ~/home/foo is o+x, but o-r
+ <braunr> 10:43 < youpi> and I have a translator running on
+ ~/home/foo/aZeRtYuyU/foo
+ <braunr> i meant, the last foo
+ <teythoon> still, this is easily fixed
+ <youpi> sure
+ <youpi> just has to be :)
+ <teythoon> youpi, braunr: so do you think that this approach will work?
+ <youpi> I believe so
+ <braunr> i still don't see the problem, so don't ask me :)
+ <braunr> i've been sick all week end and hardly slept, which might explain
+ <braunr> in the example, "all but the last path components" is
+ "~/home/foo/aZeRtYuyU"
+ <braunr> right ?
+ <youpi> braunr: well, I haven't looked at the details
+ <youpi> but be it the last, or but-last doesn't change the issue
+ <youpi> if my ~/hidden is o-r,o+x
+ <youpi> and I have a translator on ~/hidden/a/b/c/d/e
+ <youpi> checking only +x on hidden is not ok
+ <braunr> but won't the call also check a b c d ?
+ <youpi> yes, but that's not what matters
+ <youpi> what matters is that hidden is o-r
+ <braunr> hm
+ <youpi> so the mtab translator is not supposed to reveal that there is an
+ "a" in there
+ <braunr> ok i'm starting to understand
+ <braunr> so r must be checked on all components too
+ <youpi> yes
+ <braunr> right
+ <youpi> to simulate the user doing ls, cd, ls, cd, etc.
+ <braunr> well, not cd
+ <braunr> ah
+ <youpi> for being able to do ls, you have to be able to do cd
+ <braunr> as an ordered list of commands
+ <braunr> ok
+ <teythoon> agreed. can you think of any more issues?
+ <braunr> so both x and r must be checked
+ <youpi> so in the end this RPC is really a shortcut for a find + fsysopts
+ script
+ <youpi> teythoon: I don't see any
+ <braunr> teythoon: i couldn't take a clear look at the patch but
+ <braunr> do you perform a lookup on all nodes ?
+ <teythoon> yes, all nodes on the path from the root to the one specified by
+ the mount point entry in the active translator list
+ <braunr> let me rephrase
+ <braunr> do you at some point do a lookup, similar to a find, on all nodes
+ of a translator ?
+ <teythoon> no
+ <braunr> good
+ <teythoon> yes
+ <braunr> iirc, neal raised that concern once
+ <teythoon> and I'll also fix settrans --recursive not to iterate over *all*
+ nodes either
+ <braunr> great
+ <braunr> :)
+ <teythoon> fsys_set_options with do_children=1 currently does that (I've
+ only looked at the diskfs version)
+## IRC, freenode, #hurd, 2013-07-27
+ <teythoon> youpi: ah, I just found msg_get_init_port, that should make the
+ translator detection feasible
+## IRC, freenode, #hurd, 2013-07-31
+ <teythoon> braunr: can I discover the sender of an rpc message?
+ <braunr> teythoon: no
+ <braunr> teythoon: what do you mean by "sender" ?
+ <teythoon> braunr: well, I'm trying to do permission checks in the
+ S_proc_mark_essential server function
+ <braunr> ok so, the sending user
+ <braunr> that should be doable
+ <teythoon> I've got a struct proc *p courtesy of a mig intran mutation and
+ a port lookup
+ <teythoon> but that is not necessarily the sender, right?
+ <braunr> proc is really the server i know the least :/
+ <braunr> there is permission checking for signals
+ <braunr> it does work
+ <braunr> you should look there
+ <teythoon> yes, there are permission checks there
+ <teythoon> but the only argument the rpc has is a mach_port_t refering to
+ an object in the proc server
+ <braunr> yes
+ <teythoon> anyone can obtain such a handle for any process, no?
+ <braunr> can you tell where it is exactly please ?
+ <braunr> i don't think so, no
+ <teythoon> what?
+ <braunr> 14:42 < teythoon> but the only argument the rpc has is a
+ mach_port_t refering to an object in the proc server
+ <teythoon> ah
+ <braunr> the code you're referring to
+ <braunr> a common way to give privileges to public objects is to provide
+ different types of rights
+ <braunr> a public (usually read-only) right
+ <braunr> and a privileged one, like host_priv which you may have seen
+ <braunr> acting on (modifying) a remote object normally requires the latter
+ <teythoon>
+ <braunr> i thought you were referring to existing code
+ <teythoon> well, there is existing code doing permission checks the same
+ way I'm doing it there
+ <braunr> where is it please ?
+ <braunr> mgt.c ?
+ <teythoon> proc/mgt.c (S_proc_setowner) for example
+ <teythoon> yes
+ <braunr> that's different
+ <teythoon> but anyone can obtain such a reference by doing proc_pid2proc
+ <braunr> the sender is explicitely giving the new uid
+ <braunr> yes but not anyone is already an owner of the target process
+ <braunr> (although it may look like anyone has the right to clear the owner
+ oO)
+ <teythoon> see, that's what made me worry, it is not checked who's the
+ sender of the message
+ <teythoon> unless i'm missing something here
+ <teythoon> ah
+ <teythoon> I am
+ <teythoon> pid2proc returns EPERM if one is not the owner of the process in
+ question
+ <teythoon> all is well
+ <braunr> ok
+ <braunr> it still requires the caller process though
+ <teythoon> what?
+ <braunr> see check_owner
+ <braunr> the only occurrence i find in the hurd is in libps/procstat.c
+ <braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc (server, ps->pid,
+ &ps->process));
+ <braunr> server being the proc server AIUI
+ <teythoon> yes, most likely
+ <braunr> but pid2proc describes this first argument to be the caller
+ process
+ <teythoon> ah but it is
+ <braunr> ?
+ <teythoon> mig magic :p
+ <teythoon> MIGSFLAGS="-DPROCESS_INTRAN=pstruct_t reqport_find (process_t)"
+ \
+ <teythoon> MIGSFLAGS="-DPROCESS_INTRAN=pstruct_t reqport_find (process_t)"
+ \
+ <braunr> ah nice
+ <braunr> hum no
+ <braunr> this just looks up the proc object from a port name, which is
+ obvious
+ <braunr> what i mean is
+ <braunr> 14:53 < braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc
+ (server, ps->pid, &ps->process));
+ <braunr> this is done in libps
+ <braunr> which can be used by any process
+ <braunr> server is the proc server for this process (it defines the process
+ namespace)
+ <teythoon> yes, but isn't the port to the proc server different for each
+ process?
+ <braunr> no, the port is the same (the name changes only)
+ <braunr> ports are global non-first class objects
+ <teythoon> and the proc server can thus tell with the lookup which process
+ it is talking to?
+ <braunr> that's the thing
+ <braunr> from pid2proc :
+ <braunr> S_proc_pid2proc (struct proc *callerp
+ <braunr> [...]
+ <braunr> if (! check_owner (callerp, p))
+ <braunr> check_owner (struct proc *proc1, struct proc *proc2)
+ <braunr> "Returns true if PROC1 has `owner' privileges over PROC2 (and can
+ thus get its task port &c)."
+ <braunr> callerp looks like it should be the caller process
+ <braunr> but in libps, it seems to be the proc server
+ <braunr> this looks strange to me
+ <teythoon> yep, to me too, hence my confusion
+ <braunr> could be a bug that allows anyone to perform pid2proc
+ <teythoon> braunr: well, proc_pid2proc (getproc (), 1, ...) fails with
+ EPERM as expected for me
+ <braunr> ofc it does with getproc()
+ <braunr> but what forces a process to pass itself as the first argument ?
+ <teythoon> braunr: nothing, but what else would it pass there?
+ <braunr> 14:53 < braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc
+ (server, ps->pid, &ps->process));
+ <braunr> everyone knows the proc server
+ <braunr> ok now, that's weird
+ <braunr> teythoon: does getproc() return the proc server ?
+ <teythoon> I think so, yes
+ <teythoon> damn those distributed systems, all of their sources are so
+ distributed too
+ <braunr> i suspect there is another layer of dark glue in the way
+ <teythoon> I cannot even find getproc :/
+ <braunr> hurdports.c:GETSET (process_t, proc, PROC)
+ <braunr> that's the dark glue :p
+ <teythoon> ah, so it must be true that the ports to the proc server are
+ indeed process specific, right?
+ <braunr> ?
+ <teythoon> well, it is not one port to the proc server that everyone knows
+ <braunr> it is
+ <braunr> what makes you think it's not ?
+ <teythoon> proc_pid2proc (getproc (), 1, ...) fails with EPERM for anyone
+ not being root, but succeeds for root
+ <braunr> hm right
+ <teythoon> if getproc () were to return the same port, the proc server
+ couldn't distinguish these
+ <braunr> indeed
+ <braunr> in which case getproc() actually returns the caller's process
+ object at its proc server
+ <teythoon> yes, that is better worded
+ <braunr> teythoon: i'm not sure it's true actually :/
+ <teythoon> braunr: well, exploit or it didn't happen
+ <braunr> teythoon: getproc() apparently returns a bootstrap port
+ <braunr> we must find the code that sets this port
+ <braunr> i have a hard time doing that :/
+ <pinotree> isn't part of the stuff which is passed to a new process by
+ exec?
+ <teythoon> braunr: I know that feeling
+ <braunr> pinotree: probably
+ <braunr> still hard to find ..
+ <pinotree> search in glibc
+ <teythoon> braunr: exec/exec.c:1654 asks the proc server for the proc
+ object to use for the new process
+ <teythoon> so how much of hurd do I have to rebuild once i changed struct
+ procinfo in hurd_types.h?
+ <teythoon> oh noez, glibc uses it too :/
+## IRC, freenode, #hurd, 2013-08-01
+ <teythoon> I need some pointers on building the libc, specifically how to
+ point libcs build system to my modified hurd headers
+ <teythoon> nlightnfotis: hi
+ <teythoon> nlightnfotis: you rebuild the libc right? do you have any hurd
+ specific pointers for doing so?
+ <nlightnfotis> teythoon, I have not yet rebuild the libc (I was planning
+ to, but I followed other courses of action) Thomas had pointed me to some
+ resources on the Hurd website. I can look them up for you
+ <nlightnfotis> teythoon, here are the instructions
+ <nlightnfotis> and the eglibc snapshot is here
+ <teythoon> nlightnfotis: yeah, I found those. the thing is I changed a
+ struct in the hurd_types.h header, so now I want to rebuild the libc with
+ that header
+ <teythoon> and I cannot figure out how to point libcs build system to my
+ hurd headers
+ <teythoon> :/
+ <nlightnfotis> can you patch eglibc and build that one instead?
+ <pochu> teythoon: put your header in the appropriate /usr/include/ dir
+ <teythoon> pochu: is there no other way?
+ <pinotree> iirc nope
+ <pochu> teythoon: you may be able to pass some flag to configure, but I
+ don't know if that will work in this specific case
+ <teythoon> ouch >,< that explains why I haven't found one
+ <pochu> check ./configure --help, it's usually FOO_CFLAGS (so something
+ like HURD_CFLAGS maybe)
+ <pochu> but then you may need _LIBS as well depending on how you changed
+ the header... so in the end it's just easier to put the header in
+ /usr/include/
+ <braunr> teythoon: did you find the info for your libc build ?
+ <teythoon> braunr: well, i firmlinked my hurd_types.h into /usr/include/...
+ <braunr> ew
+ <braunr> i recommend building debian packages
+ <teythoon> but the build was not successful, looks unrelated to my changes
+ though
+ <teythoon> I tried that last week and the process took more than eight
+ hours and did not finish
+ <braunr> use darnassus
+ <braunr> it takes about 6 hours on it
+ <teythoon> I shall try again and skip the unused variants
+ <braunr> i also suggest you use ./debian/rules build
+ <braunr> and then interrupt the build process one you see it's building
+ object files
+ <braunr> go to the hurd-libc-i386 build dir, and use make lib others
+ <braunr> make lib builds libc, others is for companion libraries lik
+ libpthread
+ <braunr> actually building libc takes less than an hour
+ <braunr> so once you validate your build this way, you know building the
+ whole debian package will succedd
+ <braunr> succeed*
+ <teythoon> so how do I get the build system to pick up my hurd_types.h?
+ <braunr> sorry if this is obvious to you, you might be more familiar with
+ debian than i am :)
+ <braunr> patch the hurd package
+ <braunr> append your own version string like +teythoon.hurd.1
+ <braunr> install it
+ <braunr> then build libc
+ <braunr> i'll reboot darnassus so you have a fresh and fast build env
+ <braunr> almost a month of uptime without any major issue :)
+ <teythoon> err, but I cannot install my hurd package on darnassus, can I? I
+ don't think that'd be wise even if it were possible
+ <braunr> teythoon: rebooted, enjoy
+ <braunr> why not ?
+ <braunr> i often do it for my own developments
+ <braunr> teythoon: screen is normally available
+ <braunr> teythoon: be aware that fakeroot-tcp is known to hang when pfinet
+ is out of ports (that's a bug)
+ <braunr> it takes more time to reach that bug since a patch that got in
+ less than a year ago, but it still happens
+ <braunr> the hurd packages are quick to build, and they should only provide
+ the new header, right ?
+ <braunr> you can include the functionality too in the packages if you're
+ confident enough
+ <teythoon> but my latest work on the killing of essential processes issues
+ involves patching hurd_types.h and that in a way that breaks the ABI,
+ hence the need to rebuild the libc (afaiui)
+ <braunr> teythoon: yes, this isn't uncommon
+ <teythoon> braunr: this is much more intrusive than anything I've done so
+ far, so I'm not so confident in my changes for now
+ <braunr> teythoon: show me the patch please
+ <teythoon> braunr: it's not split up yet, so kind of messy:
+ <braunr> teythoon: did you make sure to add RPCs at the end of defs files ?
+ <teythoon> yes, I got burned by this one on my very first attempt, you
+ pointed out that mistake
+ <braunr> :)
+ <braunr> ok
+ <braunr> you're changing struct procinfo
+ <braunr> this really breaks the abi
+ <teythoon> yes
+ <braunr> i.e. you can't do that
+ <teythoon> I cannot put it at the end b/c of that variable length array
+ <braunr> you probably should add another interface
+ <teythoon> that'd be easier, sure, but this will slow down procfs even
+ more, no?
+ <braunr> that's secondary
+ <braunr> it won't be easier, breaking the abi may break updates
+ <braunr> in which case it's impossible
+ <braunr> another way would be to ues a new procinfo struct
+ <braunr> like struct procinfo2
+ <braunr> but then you need a transition step so that all users switch to
+ that new version
+ <braunr> which is the best way to deal with these issues imo, but this time
+ not the easiest :)
+ <teythoon> ok, so I'll introduce another rpc and make sure that one is
+ extensible
+ <braunr> hum no
+ <braunr> this usually involves using a version anyway
+ <teythoon> no? but it is likely that we need to save more addresses of this
+ kind in the future
+ <braunr> in which case it will be hanlded as an independant problem with a
+ true solution such as the one i mentioned
+ <teythoon> it could return an array of vm_address_ts with a length
+ indicating how many items were returned
+ <braunr> it's ugly
+ <braunr> the code is already confusing enough
+ <braunr> keep names around for clarity
+ <teythoon> ok, point taken
+ <braunr> really, don't mind additional RPCs when first adding new features
+ <braunr> once the interface is stable, a new and improved version becomes a
+ new development of its own
+ <braunr> you're invited to work on that after gsoc :)
+ <braunr> but during gsoc, it just seems like an unnecessary burden
+ <teythoon> ok cool, I really like that way of extending Hurd, it's really
+ easy
+ <teythoon> and feels so natural
+ <braunr> i share your concern about performances, and had a similar problem
+ when adding page cache information to gnumach
+ <braunr> in the end, i'll have to rework that again
+ <braunr> because i tried to extend it beyond what i needed
+ <teythoon> true, I see how that could happen easily
+ <braunr> the real problem is mig
+ <braunr> mig limits subsystems to 100 calls
+ <braunr> it's clearly not enough
+ <braunr> in x15, i intend to use 16 bits for subsystems and 16 bits for
+ RPCs, which should be plenty
+ <teythoon> that limit seems rather artificial, it's not a power of two
+ <braunr> yes it is
+ <teythoon> so let's fix it
+ <braunr> mach had many artificial static limits
+ <braunr> eh :D
+ <braunr> not easy
+ <braunr> replies are encoded by taking the request ID and adding 100
+ <teythoon> uh
+ <braunr> "uh" indeed
+ <teythoon> so we need an intermediate version of mig that accepts both
+ id+100 and dunno id+2^x as replies for id
+ <teythoon> or -id - 1
+ <braunr> that would completely break the abi
+ <teythoon> braunr: how so? the change would be in the *_server functions
+ and be compatible with the old id scheme
+ <braunr> how do you make sure id+2^x doesn't conflict with another id ?
+ <teythoon> oh, the id is added to the subsystem id?
+ <teythoon> to obtain a global message id?
+ <braunr> yes
+ <teythoon> ah, I see
+ <teythoon> ah, but the hurd subsystems are 1000 ids apart
+ <teythoon> so id+100 or id +500 would work
+ <braunr> we need to make sure it's true
+ <braunr> always true
+ <teythoon> so how many bits do we have for the message id in mach?
+ <teythoon> (mig?)
+ <braunr> mach shouldn't care, it's entirely a mig thing
+ <braunr> well yes and no
+ <braunr> mach defines the message header, which includes the message id
+ <braunr> see mach/message.h
+ <braunr> mach_msg_id_t msgh_id;
+ <braunr> typedef integer_t mach_msg_id_t;
+ <teythoon> well, if that is like a 32 bit integer, then allow -id-1 as
+ reply and forbid ids > 2^x / 2
+ <braunr> yes
+ <braunr> seems reasonable
+ <teythoon> that'd give us an smooth upgrade path, no?
+ <braunr> i think so
+## IRC, freenode, #hurd, 2013-08-28
+ <youpi> teythoon: Mmm, your patch series does not make e.g. ext2fs provide
+ a diskfs_get_source, does it?
+## IRC, freenode, #hurd, 2013-08-29
+ <teythoon> youpi: that is correct
+ <youpi> teythoon: Mmm, I must be missing something then: as such the patch
+ series introduces an RPC, but only EOPNOTSUPP is ever returned in all
+ cases for now?
+ <youpi> ah
+ <youpi> /* Guess based on the last argument. */
+ <youpi> since ext2fs & such report their options with store last, it seems
+ ok indeed
+ <youpi> it still seems a bit lame not to return that information in
+ get_source
+ <teythoon> yes
+ <teythoon> well, if it had been just for me, I would not have created that
+ rpc, but only guessing was frowned uppon iirc
+ <teythoon> then again, maybe this should be used and then the mtab
+ translator could skip any translators that do not provide this
+ information to filter out non-"filesystem" translators
+ <youpi> guessing is usually trap-prone, yes
+ <youpi> if it is to be used by mtab, then maybe it should be documented as
+ being used by mtab
+ <youpi> otherwise symlink would set a source, for instance
+ <youpi> while we don't really want it here
+ <teythoon> why would the symlink translator answer to such requests? it is
+ not a filesystem-like translator
+ <youpi> no, but the name & documentation of the RPC doesn't tell it's only
+ for filesystem-like translators
+ <youpi> well, the documentation does say "filesystem"
+ <youpi> but it does not clearly specify that one shouldn't implement
+ get_source if one is not a filesystme
+ <youpi> "If the concept of a source is applicable" works for a symlink
+ <youpi> that could be the same for eth-filter, etc.
+ <teythoon> right
+ <youpi> Mmm, that said it's fsys.defs
+ <youpi> not io.defs
+ <youpi> teythoon: it is the fact that we get EOPNOTSUPP (i.e. fsys
+ interface supported, just not that call), and not MIG_BAD_ID (i.e. fsys
+ interface not supported), that filters out symlink & such, right?
+ <teythoon> that's what I was thinking, but that's based on my
+ interpretation of EOPNOPSUPP of course ;)
+ <youpi> teythoon: I believe that for whatever is a bit questionable, even
+ if you put yourself on the side that people will probably agree on, the
+ discussion will still take place so we make sure it's the right side :)
+ <youpi> (re: start/end_code)
+ <teythoon> I'm not sure I follow
+ <teythoon> youpi: /proc/pid/stat seems to be used a lot:
+ <teythoon> that does not mean that start/endcode is used, but still it
+ seems like a good thing to mimic Linux closely
+ <youpi> stat is used a lot for cpu usage for instance, yes
+ <youpi> start/endcode, I really wonder who is using it
+ <youpi> using it for kernel thread detection looks weird to me :)
+ <youpi> (questionable): I mean that even if you take the time to put
+ yourself on the side that people will probably agree on, the discussion
+ will happen
+ <youpi> it has to happen so people know they agree on it
+ <youpi> I've seen that a lot in various projects (not only CS-related)
+ <teythoon> ok, I think I got it
+ <teythoon> it's to document the reasons for (not) doing something?
+ <youpi> something like this, yes
+ <youpi> even if you look right, people will try to poke holes
+ <youpi> just to make sure :)
+ <teythoon> btw, I think it's rather unusual that our storeio experiments
+ would produce such different results
+ <teythoon> you're right about the block device, no idea why I got a
+ character file there
+ <teythoon> I used settrans -ca /tmp/hello.unzipped /hurd/storeio -T
+ gunzip:file /tmp/hello
+ <teythoon> also I tried stacking the translator on /tmp/hello directly,
+ from what I've gathered that should be possible, but I failed
+ <teythoon> ftr I use the exec server with all my patches, so the unzipping
+ code has been removed from it
+ <youpi> ah, I probably still have it
+ <youpi> it shouldn't matter here, though
+ <teythoon> I agree
+ <youpi> how would you stack it?
+ <youpi> I've never had a look at that
+ <youpi> I'm not sure attaching the translator to the node is done before or
+ after the translator has a change to open its target
+ <teythoon> right
+ <teythoon> but it could be done, if storeio used the reference to the
+ underlying node, no?
+ <youpi> yes
+ <youpi> btw, you had said at some point that you had issues with running
+ remap. Was the issue what you fixed with your patches?
+ * youpi realizes that he should have shown the remap.c source code during
+ his presentation
+ <teythoon> well, I tried to remap /servers/exec (iirc) and that failed
+ <teythoon> then again, I recently played with remap and all seemed fine
+ <teythoon> but I'm sure it has nothing to do with my patches
+ <youpi> ok
+ <teythoon> those I came up with investigating fakeroot-hurd
+ <teythoon> and I saw that this also aplies to
+ <teythoon> *while
+ <youpi> yep, they're basically the same
+ <teythoon> btw, I somehow feel settrans is being abused for chroot and
+ friends, there is no translator setting involved
+ <youpi> chroot, the command? or the settrans option?
+ <youpi> I don't understand what you are pointing at
+ <teythoon> the settrans option being used by fakeroot, remap and (most
+ likely) our chroot
+ <youpi> our chroot is just a file_reparent call
+ <youpi> fakeroot and remap do start a translator
+ <teythoon> yes, but it is not being bound to a node, which is (how I
+ understand it) what settrans does
+ <teythoon> the point being that if settrans is being invoked with --chroot,
+ it does something completely different (see the big if (chroot) {...}
+ blocks)
+ <teythoon> to a point that it might be better of in a separate command
+ <youpi> Mmm, indeed, a lot of the options don't make sense for chroot
+## IRC, freenode, #hurd, 2013-09-06
+ <braunr> teythoon: do you personally prefer /proc being able to implement
+ /proc/self on its own, or using the magic server to tell clients to
+ resolve those specific cases themselves ?
+ <pinotree> imho solving the "who's the sender of an rpc" could solve both
+ the SCM_CREDS implementation and the self case in procfs
+[[hurd/translator/procfs/jkoenig/discussion]], *`/proc/self`*.
+ <braunr> pinotree: yes
+ <braunr> but that would require servers impersonating users to some extent
+ <braunr> and this seems against the hurd philosophy
+ <pinotree> and there was also the fact that you could create a
+ fake/different port when sending an rpc
+ <braunr> to fake what ?
+ <pinotree> the sender identiy
+ <pinotree> *identity
+ <braunr> what ?
+ <braunr> you mean intermediate servers can do that
+ <teythoon> braunr: I don't know if I understand all the implications of
+ your question, but the magic server is the only hurd server that actually
+ implements fsys_forward (afaics), so why not use that?
+ <braunr> teythoon: my question was rather about the principle
+ <braunr> do people find it acceptable to entrust a server with their
+ authority or not
+ <braunr> on the hurd, it's clearly wrong
+ <braunr> but then it means you need special cases everywhere, usually
+ handled by glibc
+ <braunr> and that's something i find wrong too
+ <braunr> it restricts extensibility
+ <braunr> the user can always change its libc at runtime, but in practice,
+ it's harder to perform than simply doing it in the server
+ <teythoon> braunr: then I think I didn't get the question at all
+ <braunr> teythoon: it's kind of the same issue that you had with the mtab
+ translator
+ <braunr> about showing or not some entries the user normally doesn't have
+ access to
+ <braunr> this problem occurs when there is more than one server on the
+ execution path and the servers beyond the first one need credentials to
+ reply something meaningful
+ <braunr> the /proc/self case is a perfect one
+ <braunr> (conceptually, it's client -> procfs -> symlink)
+ <braunr> 1/ procfs tells the client it needs to handle this specially,
+ which is what the hurd does with magic
+ <braunr> 2/ procfs assumes the identity of the client and the symlink
+ translator can act as expected because of that
+ <braunr> teythoon: what way do you find better ?
+ <teythoon> braunr: by "procfs assumes the identity" you mean procfs
+ impersonating the user?
+ <braunr> yes
+ <teythoon> braunr: tbh I still do not see how this can be implemented at
+ all b/c the /proc/self symlink is not about identity (which can be
+ derived from the peropen struct initially created by fsys_getroot) but
+ the pid of the callee (which afaics is nowhere to be found)
+ <teythoon> s/callee/caller/
+ <teythoon> the one doing the rpc
+ <braunr> impersonating the user isn't only about identity
+ <braunr> actually, it's impersonating the client
+ <teythoon> yes, client is the term >,<
+ <braunr> so basically, asking proc about the properties of the process
+ being impersonated
+ <teythoon> proc o_O
+ <braunr> it's not hard, it's just a big turn in the way the system would
+ function
+ <braunr> teythoon: ?
+ <teythoon> you lost me somewhere
+ <braunr> the client is the process
+ <braunr> not the user
+ <teythoon> in order to implement /proc/self properly, one has to get the
+ process id of the process doing the /proc/self lookup, right?
+ <braunr> yes
+ <braunr> actually, we would even slice it more and have the client be a
+ thread
+ <teythoon> so how do you get to that piece of information at all?
+ <braunr> the server inherits a special port designating the client, which
+ allows it to query proc about its properties, and assume it's identity in
+ servers such as auth
+ <braunr> its*
+ <teythoon> ah, but that kind of functionality isn't there at the moment, is
+ it?
+ <braunr> it's not, by design
+ <teythoon> right, hence my confusion
+ <braunr> instead, servers use the magic translator to send a "retry with
+ special handling" message to clients
+ <teythoon> right, so the procfs could bounce that back to the libc handler
+ that of course knows its pid
+ <braunr> yes
+ <teythoon> right, so now at last I got the whole question :)
+ <braunr> :)
+ <teythoon> ugh, I just found the FS_RETRY_MAGICAL handler in the libc :-/
+ <braunr> ?
+ <braunr> why "ugh" ?
+ <teythoon> well, I'm inclined to think this is the bad kind of magic ;)
+ <braunr> do i need to look at the code to understand ?
+ <teythoon> ok, so I think option 1/ is easily implemented, option 2/ has
+ consequences that I cannot fully comprehend
+ <braunr> same for me
+ <teythoon> no, but you yourself said that you do not like that kind of
+ logic being implemented in the libc
+ <braunr> well
+ <braunr> easily
+ <braunr> i'm not so sure
+ <braunr> it's easy to code, but i assume checking for magic replies has its
+ cost
+ <teythoon> why not? the code is doing a big switch over the retryname
+ supplied by the server
+ <teythoon> we could stuff getpid() logic in there
+ <braunr> 14:50 < braunr> it's easy to code, but i assume checking for magic
+ replies has its cost
+ <teythoon> what kind of cost? computational cost?
+ <braunr> yes
+ <braunr> the big switch you mentioned
+ <braunr> run every time a client gets a reply
+ <braunr> (unless i'm mistaken)
+ <teythoon> a only for RETRY_MAGICAL replies
+ <braunr> but you need to test for it
+ <teythoon> switch (retryname[0])
+ <teythoon> {
+ <teythoon> case '/':
+ <teythoon> ...
+ <teythoon> that should compile to a jump table, so the cost of adding
+ another case should be minimal, no?
+ <braunr> yes
+ <braunr> but
+ <braunr> it's even less than that
+ <braunr> the real cost is checking for RETRY_MAGICAL
+ <braunr> 14:55 < teythoon> a only for RETRY_MAGICAL replies
+ <braunr> so it's basically a if
+ <braunr> one if, right ?
+ <teythoon> no, it's switch'ing over doretry
+ <teythoon> you should pull up the code and see for yourself. it's in
+ hurd/lookup-retry.c
+ <braunr> ok
+ <braunr> well no, that's not what i'm looking for
+ <teythoon> it's not o_O
+ <braunr> i'm looking for what triggers the call to lookup_retry
+ <braunr> teythoon: hm ok, it's for lookups only, that's decent
+ <braunr> teythoon: 1/ has the least security implications
+ <teythoon> yes
+ <braunr> it could slightly be improved with e.g. a well defined interface
+ so a user could preload a library to extend it
+ <teythoon> extend the whole magic lookup thing?
+ <braunr> yes
+ <teythoon> but that is no immediate concern, you are trying to fix
+ /proc/self, right?
+ <braunr> no, i'm thinking about the big picture for x15/propel, keeping the
+ current design or doing something else
+ <teythoon> oh, okay
+ <braunr> solving /proc/self looks actually very easy
+ <teythoon> well, I'd say this depends a lot on your trust model then
+ <teythoon> do you consider servers trusted?
+ <teythoon> (btw, will there be mutual authentication of clients/servers in
+ propel?)
+ <braunr> there were very interesting discussions about that during the
+ l4hurd project
+ <braunr> iirc, shapiro insisted that using a server without trusting it
+ (and there were specific terminology about trusting/relying/etc..) is
+ nonsense
+ <braunr> teythoon: i haven't thought too much about that yet, for now it's
+ supposed to be similar to what the hurd does
+ <teythoon> hm, then again trust is not an on/off thing imho
+ <braunr> ?
+ <teythoon> trusting someone to impersonate yourself is a very high level of
+ trust
+ <teythoon> s/is/requires/
+ <teythoon> the mobile code paper suggests that mutual authentication might
+ be a good thing, and I tend to agree
+ <braunr> i'll have to read that again
+ <braunr> teythoon: for now (well, when i have time to work on it again
+ .. :))
+ <braunr> i'm focusing on the low level stuff, in a way that won't disturb
+ such high level features
+ <braunr> teythoon: have you found something related to a thread-specific
+ port in the proc server ?
+ <braunr> hurd/process.defs:297: /* You are not expected to understand
+ this. */
+ <braunr> \o/
+ <teythoon> braunr: no, why would I (the thread related question)
+ <teythoon> braunr: yes, that comment also cought my eye :/
+ <braunr> teythoon: because you read a lot of the proc code lately
+ <braunr> so maybe your view of it is better detailed than mine
+## IRC, freenode, #hurd, 2013-09-13
+ * youpi crosses fingers
+ <youpi> yay, still boots
+ <youpi> teythoon: I'm getting a few spurious entries in /proc/mounts
+ <youpi> none /servers/socket/26 /hurd/pfinet interface=/dev/eth0, etc.
+ <youpi> /dev/ttyp0 /dev/ttyp0 /hurd/term name,/dev/ptyp0,type,pty-master 0
+ 0
+ <youpi> /dev/sd1 /dev/cons ext2fs
+ writable,no-atime,no-inherit-dir-group,store-type=typed 0 0
+ <youpi> fortunately mount drops most of them
+ <youpi> but not /dev/cons
+ <youpi> spurious entries in df are getting more and more common on linux
+ too anyway...
+ <youpi> ah, after a console restart, I don't have it any more
+ <youpi> I'm getting df: `/dev/cons': Operation not supported instead
+## IRC, freenode, #hurd, 2013-09-16
+ <youpi> teythoon: e2fsck does not seem to be seeing that a given filesystem
+ is mounted
+ <youpi> /dev/sd0s1 on /boot type ext2 (rw,no-inherit-dir-group)
+ <youpi> and still # e2fsck -C 0 /dev/sd0s1
+ <youpi> e2fsck 1.42.8 (20-Jun-2013)
+ <youpi> /dev/sd0s1 was not cleanly unmounted, check forced.
+ <youpi> (yes, both /etc/mtab and /run/mtab point to /proc/mounts)
+ <tschwinge> Yes, that is a "known" problem.
+ <youpi> tschwinge: no, it's supposed to be fixed by the mtab translator :)
+ <pinotree> youpi: glibc's paths.h points to /var/run/mtab (for us)
+ <tschwinge> youpi: Oh. But this is by means of mtab presence, and not by
+ proper locking? (Which is at least something, of course!)
+ <youpi> /var/run points to /run
+ <youpi> tschwinge: yes
+ <youpi> anyway, got to run
+## IRC, freenode, #hurd, 2013-09-20
+ <braunr> teythoon: how come i see three mtab translators running ?
+ <braunr> 6 now oO
+ <braunr> looks like df -h spawns a few every time
+ <teythoon> yes, weird...
+ <braunr> accessing /proc/mounts does actually
+ <braunr> teythoon: more bug fixing for you :)
+## IRC, freenode, #hurd, 2013-09-23
+ <teythoon> so it might be a problem with either libnetfs (which afaics has
+ never supported passive translator records before) or procfs, but tbh I
+ haven't investigated this yet
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
index 5075f783..88ffc633 100644
--- a/community/gsoc/project_ideas/object_lookups.mdwn
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -40,3 +40,32 @@ accurate measurements in a system that lacks modern profiling tools would also
be helpful.
Possible mentors: Richard Braun
+# IRC, freenode, #hurd, 2013-09-18
+In context of [[!message-id ""]].
+ <teythoon> braunr: (wrt the gnumach HACK) funny, I was thinking about doind
+ the same for userspace servers, renaming ports to the address of the
+ associated object, saving the need for the hash table...
+ <braunr> teythoon: see
+ <braunr> teythoon: my idea is to allow servers to set a label per port,
+ obtained at mesage recv time
+ <braunr> because, yes, looking up an object twice is ridiculous
+ <braunr> you normally still want port names to be close to 0 because it
+ allows some data structure optimizations
+ <teythoon> braunr: yes, I feared that ports should normally be smallish
+ integers and contigious at best
+ <teythoon> braunr: interesting that you say there that libihash suffers
+ from high collision rates
+ <teythoon> I've a theory to why that is, libihash doesn't do any hashing at
+ all
+ <pinotree> there are notes about that in the open_issues section of the
+ wiki
+ <teythoon> but I figured that this is probably ok for port names, as they
+ are small and contigious
+ <neal> braunr: That's called protected payload.
+ <neal> braunr: The idea is that the kernel appends data to the message in
+ flight.
diff --git a/community/gsoc/project_ideas/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn
new file mode 100644
index 00000000..4a95eb62
--- /dev/null
+++ b/community/gsoc/project_ideas/sound/discussion.mdwn
@@ -0,0 +1,47 @@
+[[!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
+[[!taglink open_issue_documentation]]: update [[sound]] page.
+# IRC, freenode, #hurd, 2013-09-01
+ <rekado> I'm new to the hurd but I'd love to learn enough to work on sound
+ support.
+ <rekado>
+ says drivers should be ported to GNU Mach as a first step.
+ <rekado> Is this information still current or should the existing Linux
+ driver be wrapped with DDE instead?
+ <auronandace> if i recall correctly dde is currently only being used for
+ network drivers. i'm not sure how much work would be involved for sound
+ or usb
+## IRC, freenode, #hurd, 2013-09-02
+ <rekado> The sound support proposal
+ (
+ recommends porting some other kernel's sound driver to GNU Mach. Is this
+ still current or should DDE be used instead?
+ <pinotree> rekado: dde or anything userspace-based is generally preferred
+ <braunr> rekado: both are about porting some other kernel's sound driver
+ <braunr> dde is preferred yes
+ <rekado> This email says that sound drivers are already partly working with
+ DDE:
+ <rekado> So, should I just try to get some ALSA kernel parts to compile
+ with DDE?
+ <pinotree> well, what is missing is also the dde←→hurd glue
+ <braunr> rekado: there is also a problem with pci arbitration
+ <rekado> pinotree: I assumed DDEKit works with the hurd and we could use
+ any DDE/<other kernel> glue code with it
+ * rekado looks up pci arbitration
+ <pinotree> only for networking atm
+ <rekado> ah, I see.
diff --git a/contributing.mdwn b/contributing.mdwn
index b5ff6f3c..67df9d55 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -86,6 +86,8 @@ taken the time to fix it yet, but it shouldn't be very hard. The code begins
at `hurd/pfinet/ethernet.c`, `ethernet_open()`, the `device_open` call, which
produces `edev->ether_port`. Basically, one needs to catch errors like EIEIO
when using it, and in that case re-open the device.
+See also the notes on [[hurd/translator/pfinet/implementation]], *Bugs*, *IRC,
+freenode, #hurd, 2013-09-03*.
* Add a futex kernel trap to GNU Mach. This can be useful for nicer locking
primitives, including inter-process primitives. `vm_allocate` can be used as an
example in the `gnumach` source tree for how to add a kernel trap. [[!GNU_Savannah_task 6231]]
@@ -106,6 +108,7 @@ part:1:file:/home/samy/tmp/foo`). This would be libnetfs-based.
[[GSoC proposal|community/gsoc/project_ideas/valgrind ]] about this, but the
basic port could be small.
* Use libz and libbz2 in exec. See `hurd/exec/unzip.c` etc., they should be replaced by mere calls to libraries, [[!GNU_Savannah_task 6990]]
+See also the discussions on [[open_issues/exec]].
* Add `/proc/$pid/maps`. `vminfo` already has this kind of information, it's a matter of making procfs do the same. [[!GNU_Savannah_bug 32770]]
diff --git a/contributing/discussion.mdwn b/contributing/discussion.mdwn
index 5a6bfd7c..11e8ac0e 100644
--- a/contributing/discussion.mdwn
+++ b/contributing/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -19,3 +19,69 @@ Invent something.
# Mailing Lists
Add link to [[mailing_lists]] to page, and suggest following these.
+# IRC, freenode, #hurd, 2013-08-05
+ <nalaginrut> hi guys, I'm new here. I'm a developer from Guile community,
+ and I think maybe it's a proper time to do some work to make GNU stuff
+ use Guile increasingly, but I found the wiki and docs seems a bit old,
+ and I can't find an entry from Hurd source, since there're too many
+ things. Anyone point me out?
+ <nalaginrut> thanks
+ <nlightnfotis> nalaginrut what exactly is it that you need help with?
+ <nalaginrut> I've no idea, I saw MIG and I think if it's a language I can
+ write a front-end on Guile platform. But someone suggest me write hurd
+ binding will be a good start
+ <nalaginrut> I cloned incubator which is cl-binding for hurd, but I've no
+ idea too, since there's nothing in master branch
+ <pinotree> well, fixing guile on the hurd would be a start:
+ <braunr> i won't talk about this, as my personal opinion on the matter is
+ that it's not a proper time to do it
+ <braunr> but at the same time, people should do what they're interested in
+ <braunr> so feel free to do it
+ <nalaginrut> braunr: is there any reason why it's not a proper time?
+ <braunr> nalaginrut: two words: mig sucks
+ <nalaginrut> so it'll be replaced by a new stuff?
+ <teythoon> any more reasons to have alternatives, no?
+ <braunr> sure, please do it :)
+ <braunr> actually it's more than just mig
+ <braunr> the low level internals of the hurd are almost fine, but not good
+ enough to reliably develop over it
+ <braunr> gccgo is currently proving it
+ <braunr> and such projects are good opportunities to identify and fix such
+ issues
+ <braunr> but the, if you want to work on guile, be prepared to work on a
+ lot more than just guile
+ <nalaginrut> I'm afraid I have to collect the reasons and evaluate when is
+ proper to do that, if Hurd has to be redesigned, it is not a proper time
+ ;-)
+ <braunr> it also happened with openjdk, jeremie had to fix signals (!)
+ <nalaginrut> anyway, I just want a suggestion how to start
+ <pinotree> <pinotree> well, fixing guile on the hurd would be a start:
+ <nalaginrut> ok, I'll try
+ <antrik> nalaginrut: "incubator" is a somewhat strange beast. every branch
+ in there is a completely different project. you have to find the right
+ branch for the CL bindings...
+ <nalaginrut> antrik: thanks for reply, I guess it's clisp branch?
+ <pinotree> nalaginrut:
+ <antrik> nalaginrut: sounds like it :-)
+ <antrik> braunr: I'm believe it's important to encourage work on as many
+ different levels as possible. there is no motivation for fixing low-level
+ issues unless there are some interesting high-level things relying on
+ these...
+ <braunr> antrik: i agree
+ <braunr> 11:50 < braunr> but at the same time, people should do what
+ they're interested in
+ <antrik> in fact, it's pretty much impossible to identify what we really
+ need at the lower levels unless working on high-level stuff as well...
+ <braunr> yes
+ <braunr> 11:57 < braunr> but the, if you want to work on guile, be prepared
+ to work on a lot more than just guile
+ <nalaginrut> I prepare to work on Hurd, is that an fair answer?
+ <antrik> nalaginrut: perfect! ;-)
+ <nalaginrut> ;-) well, easy to say, but I'll try what I can do
+ <antrik> yeah, just see how far you get. might be an interesting ride :-)
diff --git a/faq/still_useful.mdwn b/faq/still_useful.mdwn
index 8d7e3f28..d08d2df7 100644
--- a/faq/still_useful.mdwn
+++ b/faq/still_useful.mdwn
@@ -68,6 +68,6 @@ various servers are designed for this sort of modification.
> drivers are actually Linux drivers running in a separate userland process.
> It also for instance provides very fine-grain virtualization support, such as
-> VPN for only one process, etc.
+> [[VPN for only one process|open_issues/virtualization/networking]], etc.
> etc. etc. The implications are really very diverse...
diff --git a/faq/system_port.mdwn b/faq/system_port.mdwn
index fc710a3e..ca96697c 100644
--- a/faq/system_port.mdwn
+++ b/faq/system_port.mdwn
@@ -47,3 +47,27 @@ Mach run as a POSIX user-space process|open_issues/mach_on_top_of_posix]], or
by implementing the [[Mach IPC|microkernel/mach/ipc]] facility (as well as
several others) as Linux kernel modules. While there have been some
experiments, no such port has been completed yet.
+# IRC, freenode, #hurd, 2013-09-05
+ <rah> what would be required to port the hurd to sparc?
+ <pinotree> port gnumach, write the sparc bits of mach/hurd in glibc, and
+ maybe some small parts in hurd itself too
+ <rah> what would be required to port gnumach? :-)
+ <braunr> a new arch/ directory
+ <braunr> bootstrap code
+ <braunr> pmap (mmu handling) code
+ <braunr> trap handling
+ <braunr> basic device support (timers for example)
+ <braunr> besides, sparc is a weird beast
+ <braunr> so expect to need to work around tricky issues
+ <braunr> in addition, sparc is dead
+ <rah> mmm
+ <rah> it's not totally dead
+ <rah> the T1 chips and their decendents are still in production
+ <rah> the thing is I'd like to have real hardware for the hurd
+ <rah> and if I'm going to have two machines running at once, I'd rather one
+ of them was my UltraSPARC box :-)
+ <braunr> rah: unless you work hard on it, it's unlikely you'll get it
+ <rah> braunr: of course
diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn
index c6e8d69e..544d387d 100644
--- a/glibc/signal/signal_thread.mdwn
+++ b/glibc/signal/signal_thread.mdwn
@@ -13,12 +13,11 @@ invoker of `kill` to the target process. The target process' [[signal_thread]]
job is it to listen to such messages and to set up signal handler contexts in
other threads.
-[[!tag open_issue_documentation]]
# IRC, freenode, #hurd, 2011-04-20
+[[!tag open_issue_documentation]]
<braunr> bugs around signals are very tricky
<braunr> signals are actually the most hairy part of the hurd
<braunr> and the reason they're aynchronous is that they're handled by a
@@ -50,3 +49,43 @@ other threads.
<braunr> mach and the hurd were intended to be "hyperthreaded"
+# IRC, freenode, #hurd, 2013-09-17
+ <teythoon> I just realized that I know next to nothing about signal
+ handling on the Hurd...
+ <teythoon> especially /hurd/inits role in it
+ <teythoon> reading glibcs kill.c it does not involve /hurd/init at all, but
+ /hurd/init is full of proxying code for the msg protocol
+ <teythoon> ah, /hurd/init mitms the signal handling logic in the libc for
+ its own signals
+ <teythoon> for msg_sig_post it sends a reply immediately, and then
+ processes the signal, I wonder why that is done
+ <teythoon> also it "forwards" any signals it receives to the child it
+ spawned (like /etc/hurd/runsystem), I wonder why...
+ <teythoon> good thing the comments tell what is done, not why...
+ <teythoon> so in theory kill -HUP 1 should have been forwarded to the
+ "runsystem" process, I wonder why that does not work if that one execs
+ sysvinit
+ <braunr> teythoon: can't help you there :/
+ <teythoon> braunr: I think I sorted it out on my own, we'll see how that
+ works out in practice ;)
+ <braunr> good
+## IRC, freenode, #hurd, 2013-09-18
+ <teythoon> braunr: I figured out why /hurd/init does this strange thing
+ with the msg protocol
+ <teythoon> braunr: it has no signal thread
+ <teythoon> I wonder how /hurd/exec and the initial filesystem handle
+ this...
+ <teythoon> err, afaics the signal thread is created in fork(), so any
+ process not created using it (ie manually using task_create) should lack
+ the signal thread, no?
+ <teythoon> that'd be the root fs, /hurd/{exec,init,auth,proc} and
+ /etc/hurd/runsystem (the child started by /hurd/init)
+ <teythoon> but I see only /hurd/init doing something about it, namely
+ setting a msgport and handling the msg protocol, relaying any messages to
+ the signal handling logic in the glibc
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index 1570df4c..d62a4387 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -16,6 +16,17 @@ doing.
See `rpctrace --help` about how to use it.
+# IRC, freenode, #hurd, 2013-07-29
+ <teythoon> about rpctrace, it poses as the kernel for its children, parses
+ and relays any messages sent over the childrens message port, right?
+ <braunr> teythoon: rpctrace doesn't "poses as the kernel"
+ <braunr> well, it's close enough
+ <teythoon> but it intercepts messages send by its children by handing them
+ a message port different from the one provided by the kernel, doesn't it?
+ <braunr> yes
# Issues and Patches
[[!tag open_issue_hurd]]
@@ -186,6 +197,34 @@ See `rpctrace --help` about how to use it.
<pinotree> wish: make rpctrace decode the results of io_stat rpcs
+* IRC, freenode, #hurd, 2013-07-29
+ <teythoon> imho rpctrace is kind of a mess right now :-/ we should move the
+ parsing code to a library
+ <teythoon> that would also be useful for valgrind, it should have to do
+ basically the same
+* IRC, freenode, #hurd, 2013-07-29
+ <teythoon> and I tried to rpctrace a subhurd, but rpctrace died on a
+ assertion failure, some msg had an unexpected type or something
+ <braunr> rpctrace dies on select
+ <braunr> and guess what, the boot tool does call select on the console it
+ emulates
+ <teythoon> that's a shame, that'd be really useful for me
+ <braunr> it might not be hard to fix
+ <braunr> but i've never looked into it :/
+ <braunr> i only saw that rpctrace expects the common RPC message types
+ <braunr> and select is all but a common RPC
+ <braunr> so the type of the messages involved is slightly different
+ <braunr> and the assertion chokes on that
+ <teythoon> rpctrace.c is huge and hand written, it'd be nice if the parser
+ was created from the procedure definitions
+ <teythoon> and thinking of that, mig does exactly that, one would only need
+ some glue code
+ <braunr> select is partially hand written
+ <braunr> but it's a special case so that's ok
# See Also
diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn
index 8eac39fe..b2e7f7a9 100644
--- a/hurd/libstore.mdwn
+++ b/hurd/libstore.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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
`libstore` is used to provide a generic interface to access data (read/write)
on backing stores.
@@ -15,6 +15,8 @@ on backing stores.
It more than just a thin layer between [[GNU Mach|microkernel/mach/gnumach]]
devices (`hd0` for example) and the device node below `/dev/`...
# Available Stores
@@ -34,3 +36,32 @@ can be found.
pages="hurd/libstore/examples/* and !*/discussion"
+# Open Issues
+## IRC, freenode, #hurd, 2013-07-29
+[[!tag open_issue_documentation open_issue_hurd]]
+ <teythoon> and I read hammys paper about mobile code, is it true that the
+ store code is loaded into the client? who is the server and who is the
+ client in this context?
+ <braunr> teythoon: "store code" ?
+ <teythoon> libstore
+ <braunr> the hurd libstore ?
+ <teythoon> yes
+ <braunr> hum, what paper ?
+ <teythoon> braunr:
+ <braunr> how nice
+ <tschwinge> braunr:
+ <teythoon> it raises an important point btw, the authentication done by
+ processes on the Hurd is one sided, only the client authenticates at the
+ server
+ <braunr> yes
+ <tschwinge> It'S also mentioned in
+ -- but of
+ course, any results he got from his work really should be integrated more
+ properly into the existing body of documents.
+ <tschwinge> As with so many other documents/discussions/etc. ;-|
diff --git a/hurd/libstore/part.mdwn b/hurd/libstore/part.mdwn
index 5260d05d..29ef9072 100644
--- a/hurd/libstore/part.mdwn
+++ b/hurd/libstore/part.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -28,6 +29,132 @@ A similar problem is described in
[[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented.
+# Open Issues
-How to use, etc.
+## Documentation
+[[!tag open_issue_documentation]]
+## [[open_issues/hurd_build_without_parted]]
+## IRC, freenode, #hurd. 2013-09-21
+ <phcoder> Hello, guys. Is there a way to know where partition starts on
+ hurd. E.g. given hd0s1 get "2048 sectors"
+ <youpi> yes, it's the storeinfo RPC
+ <youpi> let me find you a pointer
+ <phcoder> in GRUB 2 files for determining device relations are a mess of
+ #if's. I try to split it into logical files and make common logic
+ uniform. Current Hurd's logic is completely different and, actually,
+ wrong. Same logic is used by Mac OS X part ...
+ <youpi> phcoder: Mmm, I guess you never got the userland-part.patch
+ upstream
+ <youpi> ah, yes ,you did
+ <youpi> I mean the find_hurd_root_device function
+ <youpi> grub was previously using file_get_storage_info
+ <phcoder> youpi: find_hurd_root_Device/file_get_storage info is about
+ translating / -> /dev/hd0s1. Current problem is in step hd0s1 ->
+ hd0,msdos1
+ <youpi> yes, but iirc file_get_storage_info might work for hd0s1 itself
+ <phcoder> I see, let me try this
+ <phcoder> youpi: file_get_storage gives offset=0 size=partition size
+ <youpi> (file_get_storage) damn
+ <phcoder> and name=hd0s1
+ <youpi> ah, that might be because we're still using in-kernel partition
+ table, instead of the parted partition table
+ <phcoder> looks like file_get_storage would be useful to get block size
+ though
+ <phcoder> youpi: is parted already used in some cases? Any reliable way to
+ check for it? Any way to access kernel partition map? Ioctl? RPC to
+ kernel?
+ <youpi> the parted table is only enabled in the debian installer for
+ now. You can set up one for yourself by running e.g. settrans -c
+ /tmp/myhd0s1 /hurd/storeio -T typed part:1:device:hd0
+ <youpi> I don't think there is any ioctl/RPC to get the kernel partition
+ table
+ <phcoder> youpi: is it using Linux partition code with some glue?
+ <youpi> phcoder: the kernel partition table, yes
+ <phcoder> youpi: that's bad. it's probably one of the least consistent
+ numbering schemes. It would imply that it only worked because only
+ simplest cases were ever tested
+ <youpi> I know
+ <youpi> that's why we want to migrate to the parted-based partition table
+ support
+ <youpi> (which also brings us much better support than the old linux2.0
+ code :) )
+ <phcoder> youpi: I've looked into code and must say that I dislike what I
+ see: partitions handled in ide/ahci/sd/...
+ <youpi> phcoder: which code?
+ <phcoder> youpi: gnumach
+ <youpi> sure, that's not what we want in the end
+ <phcoder> grep -r start_sect
+ <youpi> it's just the legacy linux way of doing partition support
+ <phcoder> Well Linux at least gives a meaningful ioctl
+ <phcoder> couldn't find any hint of it in gnumach
+ <youpi> we didn't bother to add one since the parted way is supposed to be
+ what we have in the end
+ <phcoder> youpi: I can't make our code follow sth that might be the case in
+ the future
+ <youpi> why not?
+ <youpi> that's the way we will go
+ <youpi> it's not just hypothetic
+ <youpi> we just can't continue maintaining disk drivers in the kernel
+ <youpi> so it won't be in the kernel
+ <phcoder> youpi: if I do then GRUB won't work on current GNU/Hurd anymore
+ <youpi> can't you also keep the old code?
+ <youpi> as a fallback when the proper way does not work (yet)
+ <phcoder> More hairs... :(
+ <phcoder> How do I check for it? offset == 0 isn't proper as partitions may
+ start at 0
+ <phcoder> but checking than name still refers to partition is probably the
+ right way
+ <youpi> I don't see what you mean
+ <youpi> (about name)
+ <phcoder> youpi: I mean that we need a way to know that current code is
+ used and not future parted-based code
+ <youpi> phcoder: I understand that for the offset ==0 thing
+ <youpi> but I didn't understand the phrase you wrote just after that
+ <phcoder> youpi: file_get_storage gives back a name. If this name is the
+ same as the partition we requested in the first place then it's current
+ code
+ <youpi> ah, ok
+ <youpi> yes, if the name is the same, it means it's not actually a
+ partition
+ <phcoder> youpi: current gnumach code makes fake devices out of partitions
+ <youpi> yes
+ <phcoder> youpi: with settrans command you told, I get num_ints = 0
+ <youpi> phcoder: odd, I do get information, e.g.:
+ <youpi> hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio -T typed
+ part:1:device:sd0
+ <youpi> hurd:/tmp# storeinfo mysd0s1
+ <youpi> device (0x200): sd0: 512: 83905: 42959360: 63+83905
+ <phcoder> storeinfo: myhd0s1: Operation not supported
+ <youpi> do you actually have an hd0 device?
+ <phcoder> yes
+ <phcoder> youpi: I typed parted instead of part
+ <phcoder> Now it works
+ <youpi> good :)
+ <phcoder> youpi: what is expected timeline on migration to part interface?
+ <youpi> there's no real timeline
+ <youpi> like everything, it'll happen when somebody actually looks at how
+ to achieve it
+ <youpi> perhaps it'll be easy, perhaps not. IIRC there is still an issue
+ with the swapper
+ <phcoder> youpi: sounds like we're stuck will fallback code for at least
+ couple of years
+ <youpi> possibly, entirely depends on people taking the task
+ <youpi> if that becomes really pressing at some point, I'll have to do it,
+ but of course, I can not magically do everything in a glimpse
+ <phcoder> youpi: it's not pressing but just be aware that unusual
+ partitioning is likely to fail. Probably not huge issue. As to its place
+ in our code it's not ideal but it's not the only case of suboptimal
+ construction for specific systems (what we had to do because of Linux
+ caching is terrifying). I'm not going to make hurd code a scapegot of
+ more generic problem
+ <phcoder> youpi: and since we very rarely drop support this code is
+ probably stuck for good
+ <youpi> as long as it's not used whenever we get to move to parted-based
+ partitioning, it's not too bad
+ <phcoder> youpi: and Mac OS X/Darwin case is even worse. Apparently they
+ deprecated their *BSD functions (which probably don't work since they
+ don't use BSD labels) without giving any replacement.
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
index afa46799..849ff382 100644
--- a/hurd/running/debian/dhcp.mdwn
+++ b/hurd/running/debian/dhcp.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -29,3 +30,97 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from
* [[!debbug 616290]]
* [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]]
+ * [[!message-id desc="dhclient aborting with a stack smashing error"
+ ""]]
+ IRC, freenode, #hurd, 2013-08-21:
+ <teythoon> yay, I fixed the path of the dhcp leases file...
+ <teythoon> ... and now dhclient dies of a buffer overflow
+ <teythoon> fortunately the fix is rather simple, anyone who cares about
+ the security of his box just has to stop using isc software
+ <teythoon> the code is full of stuff like char foo[100]; /* surely
+ that's enough */
+ <pinotree> note that our version of isc-dchp (the one in ports) is
+ older than the latest one available in unstable (which is still older
+ than the latest upstream releases)
+ <teythoon> so?
+ <pinotree> dunno, might have been fixed or not
+ <teythoon> ^^ yeah sure
+ <gnu_srs> A lot of software has these limitations and PATH_MAX,
+ MAXPATHLEN issues :(
+ <pinotree> having a limitation is not a problem per-se
+ <teythoon> no, only software written in c has these kind of problems
+ <pinotree> the problem is not checking whether the limits are hit
+ <teythoon> well, looking at the source of isc-dhcp my time is better
+ spent making another dhcp client work on hurd
+ <teythoon> also reading up on bug #616290 does make me want to avoid
+ touching it ever
+ <braunr> hehe
+ <gnu_srs> teythoon: somebody was offering an alternative to the isc
+ dhcpclient, but I think it was rejected by Samuel?
+ <teythoon> why would he do that?
+ <braunr> probably for compliance
+ <gnu_srs> He probably thought they would release a new version soon, is
+ 4.3.0 out yet?
+ <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will
+ start crashing
+ <teythoon> no, there is no new version released
+ <teythoon> no major one that is
+ <teythoon> 4.2.5 is out
+ <gnu_srs> can't you just increase the buffer size, where is the problem
+ exactly?
+ <teythoon> I have no idea
+ <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for
+ 4.3.0a1.
+ <gnu_srs> Still the buffer overflow problem might be present in 4.2.5
+ if patched to build on Hurd.
+ <braunr> there, darnassus now has a fully featured git/gitweb service
+ <teythoon> :)
+ <teythoon> btw, I managed to reproduce the crash reliably
+ <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0 ... *boom*
+ <teythoon> ditch the -v, everything works, and now that there is a
+ lease file, you can add the -v again and it works
+ <braunr> ew :)
+ <teythoon> and what has dhclient.c to say for its defense?
+ <teythoon> log_info("%s", "");
+ <teythoon> hm, not much :/
+ IRC, freenode, #hurd, 2013-08-22:
+ <teythoon> uh, the isc-dhcp situation is a huge pita, the source on
+ -ports does not compile anymore :/
+ IRC, freenode, #hurd, 2013-08-23:
+ <gnu_srs> teythoon: Was it the slash in the network interface names
+ that caused the buffer overflow in dhclient?
+ <teythoon> gnu_srs: no, previously no dhcp leases file was written and
+ everything was fine
+ <pinotree> teythoon: did you really develop your patch against that old
+ version of ifupdown?
+ <teythoon> gnu_srs: now it is written, and for some reason dhclient
+ crashes *iff* -v is given *and* there is no previous lease file
+ <teythoon> pinotree: no, I did not. that was only reportbug including
+ information from my desktop machine without asking me
+ <teythoon> but when I first looked at ifupdown it was still a 6000
+ lines noweb file >,<
+ <teythoon> that was fun
+ <pinotree> which version is it against?
+ <teythoon> hg tip
+ IRC, freenode, #hurd, 2013-08-30:
+ <tschwinge> teythoon: I understand correctly that you found that
+ id:"" in fact was really
+ "just" a buffer overflow in the dhclient code?
+ <teythoon> tschwinge: ah, most interesting, I didn't realize that you
+ stumbled across this as well
+ <teythoon> to be honest I don't know what's going on there, I only
+ observed what I wrote in my report
+ <teythoon> for me it started crashing once the lease file was actually
+ a valid path (i.e. not to a non-existing directory b/c of the slashes
+ in /dev/eth0)
+ <teythoon> I tried to rebuild the package served on debian-ports, but
+ that failed
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
index f2117ead..55bead37 100644
--- a/hurd/subhurd.mdwn
+++ b/hurd/subhurd.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 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
@@ -42,6 +42,22 @@ set up another Hurd on a different partition, without ever rebooting. (You can
run the `native-install` step from a chroot or already in a subhurd.)
+### IRC, freenode, #hurd, 2013-09-15
+ <gnu_srs> Never dared to try a subhurd, any link to the howto?
+ <teythoon> gnu_srs: I followed
+ though using crosshurd
+ didn't work for me, I just used debootstrap
+ <teythoon> gnu_srs: and you need a separate filesystem translator (i.e. not
+ /) for that
+ <teythoon> the easiest way is to add another virtual disk to you qemu setup
+ <braunr> use the qemu image directly
+ <braunr> simplest way to set up a subhurd
+ <braunr> just change fstab from the host before the first boot to avoid
+ making the subhurd use the same hd0 drive as the host
+ <teythoon> braunr: nice idea :)
## Booting
To boot the subhurd, you need a boot script. For historical reasons, usually
@@ -118,6 +134,362 @@ look at the number of threads (e.g. using `ps -l`), as many servers have very
characteristic thread counts.
+### IRC, freenode, #hurd, 2013-08-09
+ <teythoon> btw, is there a way to get dde-based networking into a subhurd?
+ <teythoon> the wiki instructions look like they're for the mach driver
+ <teythoon> and starting the dde translator inside the subhurd does not work
+ for me
+ <teythoon> that's probably a good thing though
+ <youpi> the netdde process will need privileged access to mach
+ <youpi> for hardware access
+ <braunr> you can't easily use netdde from a subhurd, unless with a
+ different nic
+ <braunr> i usually rebuild mach with in kernel devices so both the main and
+ subhurd can share on nic
+ <braunr> one*
+ <youpi> could a port to netdde perhaps forwarded to the subhurd?
+ <braunr> zengh da wrote the eth-multiplexer for that iirc
+ <youpi> it's a matter of making it appear as an eth0 device on the master
+ port aiui
+ <braunr> zheng*
+ <teythoon> yes, I looked at that
+ <teythoon> what is the master port?
+ <youpi> on a plain hurd system it's the port that privileged processes can
+ use to access mach devices
+ <youpi> in a subhurd, it's the same for the subhurd, to access some devices
+ that you choose to give access to
+ <braunr> its real name is the "device master port"
+ <teythoon> ah yes
+#### IRC, freenode, #hurd, 2013-08-10
+ <antrik> teythoon: use eth-multiplexer to use the NIC within a
+ subhurd. that's exactly what it was created for.
+ <antrik> I don't remember whether it's even possible to share a "raw"
+ netdde device... I don't think I ever tried that; and I don't remember
+ enough of the theory to tell whether it should be possible
+ <antrik> but I really don't see the reason to, when eth-multiplexer is
+ available
+ <antrik> (IMHO running an eth-multiplexer on top of netdde should be the
+ default setup in fact)
+ <antrik> as for actually passing on the device, that should be perfectly
+ possible with zhengda's modified subhurd... but I don't remember whether
+ that was ever merged upstream
+ <antrik> (you will definitely need that for using netdde in a subhurd,
+ regardless whether through eth-multiplexer or directly)
+#### IRC, freenode, #hurd, 2013-09-15
+ <teythoon> I wonder if we can modify the boot program so that it passes
+ ports from the mother hurd to the subhurd
+ <teythoon> so that we could pass in a port to the eth-multiplexer
+ <teythoon> or use like /hurd/remap as the root translator for the subhurd
+ <braunr> eth-multiplexer was created exactly for that iirc,
+ <braunr> so it's probably already done somewhere
+#### IRC, freenode, #hurd, 2013-09-16
+ <gnu_srs> braunr: regarding subhurd did you mean to install
+ sthibault/hurd-i386/debian-hurd.img.tar.gz
+ <gnu_srs> on a separate partition and booting using the instructions for
+ subhurds on the web.
+ <braunr> gnu_srs: yes
+ <braunr> be careful that the subhurd doesn't use the same partition as the
+ main hurd, that's all
+ <gnu_srs> what about changing fstab?
+ <braunr> 12:17 < braunr> be careful that the subhurd doesn't use the same
+ partition as the main hurd, that's all
+ <teythoon> gnu_srs: yes, you need to change the fstab
+ <teythoon> currently it is used for fscking stuff, so if it points to your
+ main partition it will cause severe corruption
+ <teythoon> gnu_srs: you also have to specify the right partition in the
+ servers.boot file
+ <gnu_srs> fstab of the subhurd image?
+ <teythoon> yes
+ <gnu_srs> how to unpack the .img file (just to be sure)?
+ <teythoon> gnu_srs: you don't need to, just use the img file as secondary
+ hard disk image
+ <gnu_srs> Then how should I be able to change fstab of the image?
+ <teythoon> boot your hurd box, mount the partition and change it
+ <gnu_srs> I missed something here: on my partition /my_chroot I have have
+ the file debian-hurd-20130504.img
+ <teythoon> gnu_srs: ah, you copied it to the partition, braunr meant to use
+ it as the secondary disk, e.g. qemu ... -hdb debian-hurd-20130504.img ...
+ <gnu_srs> That is the same as installing another cd image, where does the
+ subhurd come into play?
+ <teythoon> mount the partition on the secondary hd, fix the fstab there,
+ mount it r/o, get the servers.boot file from the wiki, modify it so that
+ it points to the right partition, execute boot servers.boot /dev/<your
+ partition>, probably /dev/hd1s1
+ <gnu_srs> BTW: unpacking was problematic: tar: debian-hurd-20130504.img:
+ Cannot seek to 2147696640 (2G limitations)
+ <teythoon> I wonder why you did this on your hurd system in the first
+ place...
+ <gnu_srs> I thought I could use that partition, /my_chroot as a chroot
+ place. So it won't work for subhurds?
+ <teythoon> well, there are several ways to setup a subhurd. one is to
+ already have a spare partition for that and use crosshurd or as I did
+ debootstrap to install a debian system there
+ <teythoon> braunr suggested an even easier way, download the .img file and
+ use it as secondary hard disk
+ <teythoon> you ended up doing kind of both
+ <gnu_srs> I tried once with debootstrap and that created a disaster...
+ <teythoon> how so?
+ <gnu_srs> The install errored out, and the whole filesystem (including /)
+ was left in a broken state. Maybe I tried
+ <gnu_srs> that without using a separate partition. Don't remember any
+ longer. So you say it's safe now?
+ <teythoon> I used it successfully to setup my subhurd
+ <gnu_srs> and you have your subhurd in a separate partition, installed from
+ there too, as root?
+ <gnu_srs> the web page only mentions crosshurd, and that failed for you?
+ <teythoon> yes, having a separate partition is (currently) necessary to run
+ a subhurd
+ <teythoon> yes, I used debootstrap as root, afaics that is necessary
+ <teythoon> and yes, as I said the other day, I tried crosshurd first and it
+ failed
+ <teythoon> then again, I fail to see any reason to use crosshurd these days
+ <teythoon> it's only a wrapper around debootstrap anyway, using it with
+ --foreign and fixing up stuff later
+ <teythoon> one has more control over the process if one uses debootstrap
+ directly
+ <gnu_srs> I still don't dare to do it yet. I'll create another image using
+ netinst with a separate partition and try out first.
+ <gnu_srs> When installing a new image using netinst.iso (2013-06-30) and
+ rebooting /proc does not get mounted?
+ <teythoon> gnu_srs: is that a statement or a question?
+ <gnu_srs> A statement.
+ <teythoon> it's not customary to end statements with question marks ;)
+ <gnu_srs> s/mounted?/mounted, why?/
+ <teythoon> well, you seem to be the last person to perform such an
+ installation, so you are in the perfect position to answer this question.
+ <gnu_srs> cat /var/log/dmesg?
+ <gnu_srs> On other images I have: fsysopts /proc; /hurd/procfs
+ --clk-tck=100 --stat-mode=444 --fake-self=1
+ <youpi> gnu_srs: no, check the installation log
+ <youpi> gnu_srs: and what does showtrans say?
+ <gnu_srs> showtrans /proc; <empty>
+ <gnu_srs> which log file to look for?
+ <youpi> the installation log, somewhere in /var/log probably
+ <gnu_srs> I only find /proc in /var/log/installer/syslog, mainly printing
+ out errors not finding /proc/mounts
+ <youpi> iirc the /proc translator should be set during the hurd package
+ configuration
+ <youpi> you should probably look for that part in the log
+ <youpi> Setting up translators: /hurd/exec /hurd/proxy-defpager
+ /hurd/pflocal (+link) /hurd/pfinet (+link) (+link) /hurd/procfs -c
+ /hurd/password crash-kill crash-suspend crash-dump-core crash.
+ <youpi> that part
+ <gnu_srs> debootstrap: /hurd/procfs -c and in-target: /hurd/procfs -c No
+ errors
+ <youpi> I don't understand what that means
+ <youpi> please explain in more details
+ <gnu_srs> see:
+ <youpi> makes much more sense :)
+ <gnu_srs> Where is the 'Setting up translators' done? I cannot find
+ anything in /var/lib/dpkg/info/hurd* or /etc/init.d/...
+ <pinotree> /usr/lib/hurd/setup-translators, called in hurd.postinst
+ <gnu_srs> tks:)
+ <gnu_srs> Hi, when installing a new image with debootstrap to /chroot the
+ script boot/servers.boot is already there (as well as in /boot/ + grub)
+ <gnu_srs> Is it OK to use that file to boot the subhurd?
+ <gnu_srs> using /boot/servers.boot or /chroot/boot/servers.boot (if the
+ /chroot partition is unmounted it cannot be used?)
+ <gnu_srs> and how to unmount /chroot: umount does not work?
+ <gnu_srs> braunr: I'm also trying to find out what's wrong with glibc, when
+ my subhurd is up and running 2.13-39 (if possible)
+ <gnu_srs> I know I should issue settrans command, but I'm not yet fluent in
+ translators.
+ <gnu_srs> sorry:-/
+ <gnu_srs> Now this, after a reboot: unknown code P 30 while trying to open
+ /dev/hd0s3 (/chroot)
+ <gnu_srs> Disk write protected: use the -n option to do a read-only check
+ of the device.
+ <gnu_srs> fsysopts /dev/&hd0s1 --writable: Operation not supported??
+ <gnu_srs> OK, I'm giving up for now, no subhurd:-( and a broken install.
+ <gnu_srs> Which terminal to use in rescue mode, TERM is not set,
+ dumb,mach,hurd does not work with nano?
+ <gnu_srs> e2fsck /dev/ho0s3; e2fsck: Unknown code P 2 while trying to open
+ /dev/ho0s3; Possibly non-existent device?
+ <gnu_srs> mke2fs /dev/hd0s3; /dev/hd0s3 is not a block special device.;
+ Proceed anyway? (y,n) n: What's going on (hd0s3 not mounted)??
+ <gnu_srs> anybody, help?
+ <gnu_srs> after removing and creating the partition again:mke2fs
+ /dev/hd0s3, <same>, mke2fs: Unknown code P 13 while trying to determine
+ filesystem size: What's going on?
+ <gnu_srs> Where to find the glibc-2.13 versions which used to be at
+ debian-ports?.
+ <gnu_srs> seems they can be found on
+#### IRC, freenode, #hurd, 2013-09-17
+ <gnu_srs> teythoon: Installing subhurd via debootstrap on partition
+ /chroot fails miserably. Install hangs, and after reboot \rm -r
+ /chroot/* fails for dev and proc
+ <gnu_srs> Are there translators running there already? I have not
+ booted the subhurd.
+ <gnu_srs> translators for hd0s3 (/chroot) are storeio and
+ ex2fs.static. Do I have to stop them to be able to clean out
+ /chroot?
+ <gnu_srs> mount -v /chroot; settrans -a /chroot /hurd/ext2fs
+ /dev/hd0s3;
+ <gnu_srs> ext2fs: /dev/hd0s3: panic: main: device too small for
+ superblock (0 bytes);
+ <gnu_srs> mount: cannot start translator /hurd/ext2fs: Translator
+ died
+ <gnu_srs> Please, somebody!
+ <gnu_srs> don't ask to ask, just ask, right?
+ <braunr> we've already told you everything you need
+ <braunr> just get it right
+ <braunr> for example, i told you to be careful about fstab so that
+ the subhurd wouldn't use the main hurd partition
+ <braunr> but you managed to screw that
+ <braunr> good job
+ <gnu_srs> I installed the subhurd in a partition /chroot /dev/hd0s3
+ using debootstrap
+ <braunr> i don't know deboostrap, it may be broken, use the disk
+ image youpi maintains
+ <gnu_srs> ant the install screwed up with debootstrap
+ <gnu_srs> ok; then I cannot use a partition, but another disk in
+ kvm, e.g. hdb?
+ <braunr> gnu_srs: hd1
+ <gnu_srs> something is fishy with glibc, definitely, that's why I'm
+ trying to set up a subhurd to revert to 2.13-39
+ <gnu_srs> hi, when trying to boot a subhurd: /hurd/ext2fs.static:
+ hd0s3: Gratuitous error; bye
+ <braunr> gnu_srs: why hd0s3 ?
+ <braunr> it should be hd1s1
+ <gnu_srs> I'm still using a separate partition /my_chroot
+ /hd0s3. Will switch to hd1 next. teythoon?
+ <gnu_srs> the servers.boot script use absolute
+ paths:/hurd/ext2fs.static and /lib/ /hurd/exec,
+ <gnu_srs> shouldn't they be relative to /my_chroot?
+ <braunr> no
+ <braunr> they're actually from your host
+ <gnu_srs> teythoon: please, how did you succeed to boot a subhurd
+ in a partition?
+ <gnu_srs> using debootstrap
+ <teythoon> gnu_srs: from my shell history:
+ <teythoon> : 1374672426:0;debootstrap sid /mnt
+ <teythoon> : 1374673020:0;cp /etc/hosts /etc/resolv.conf /mnt/etc
+ <teythoon> : 1374673048:0;cp /etc/passwd /etc/shadow /mnt/etc
+ <braunr> teythoon: so it does work fine ?
+ <braunr> great
+ <teythoon> yes, why wouldn't it?
+ <teythoon> gnu_srs: I then remounted that partition r/o and used
+ the servers.boot file from the wiki to boot it
+ <teythoon> braunr: why wouldn't it? (you do mean the debootstrap
+ part, don't you?)
+ <braunr> teythoon: i don't know
+ <braunr> i've heard it wasn't maintained any more
+ <braunr> not being maintained is a good reason for something to
+ become unusable/untrustable with time
+ <teythoon> o_O it is at the heart of d-i, isn't it?
+ <teythoon> I actually do most Debian installations using
+ debootstrap directly
+ <braunr> ah
+ <braunr> ok :)
+ <braunr> teythoon: even hurd ones ?
+ <teythoon> braunr: well, just the subhurd installation, but that
+ went as expected
+ <braunr> good
+ <gnu_srs> Finally: I found the reason for Gratuitous error, I used
+ the /boot/servers.boot script,
+ <gnu_srs> that being different to the one on the wiki:-/
+ <gnu_srs> Is it possible to copy files between a host hurd and
+ subhurd, what about access to eth0?
+ <gnu_srs> Hi, when starting the subhurd I see some warnings/error:
+ <gnu_srs> 1) A spelling error execunable-> executable
+ <gnu_srs> 2) libports: invalid destination port
+ <gnu_srs> 3) mach-defpager: another already running
+ <pinotree> "execunable" is not a typo, but just "exec" and "unable
+ ..." without a space-type character
+ <gnu_srs> OK, sounds more plausible
+ <gnu_srs> Ah, the printouts are mixed, no bug
+ <gnu_srs> When setting up nework in the subhurd: /hurd/pfinet:
+ file_name_lookup /dev/eth0: Translator died
+ <gnu_srs> /hurd/pfinet: device_open(/dev/eth0): (os/device) no such
+ device
+ <gnu_srs> settrans: /hurd/pfinet: Translator died
+#### IRC, freenode, #hurd, 2013-09-18
+ <youpi> priority does not matter much
+ <youpi> memory manager is not really surprising, there's indeed already one
+ <youpi> what is actually the problem?
+ <gnu_srs> So these are merely warnings?
+ <youpi> gnu_srs: yes
+ <gnu_srs> Real problems are I cannot set up networking, e.g. wget ...:
+ Connecting to ... failed: Address family not supported by protocol.
+ <youpi> gnu_srs: did you give the subhurd a network card?
+ <gnu_srs> How?
+ <gnu_srs> and do I need to set up fstab, for now it's empty.
+ <gnu_srs> I just installed the base with dbootstrap
+ <youpi> gnu_srs: -f option of boot
+ <youpi> e2fsck will need fstab for sure
+ <youpi> otherwise it can't divine what should be checked
+ <gnu_srs> Why is the /boot/servers.boot different from the subhurd one on
+ the wiki? Is it used at all, I thought grub was in charge.
+ <youpi> it's not used at all
+ <gnu_srs> maybe better to put in the subhurd one there then, with a
+ comment?
+ <youpi> no, since /boot/servers.boot is supposed to be used for machine
+ boot
+ <youpi> not subhurd boot
+ <gnu_srs> what about putting a copy of the suhurd one there, with a
+ different name?
+ <youpi> probably a good idea, yes
+ <youpi> matter of making it happen
+ <gnu_srs> the wiki page on subhurd does not say how to set up networking,
+ only that you can do it.
+ <youpi> matter of adding the information
+ <youpi> I remember it's the -f option of boot
+ <youpi> make it work, and add the information for others
+ <gnu_srs> I could try, but don't know how to add a network card to the
+ subhurd, and e.g. how to set up swap
+ <youpi> see -f option
+ <gnu_srs> of boot?
+ <youpi> "gnu_srs: -f option of boot"
+ <youpi> if you could read what we write, that'd make things happen way
+ faster
+ <gnu_srs> yes I saw your comment above, it was just to be 100% sure:-D
+ <gnu_srs> device_file=/dev/eth0 or something else?
+ <gnu_srs> eth0 is used by the host already
+ <youpi> did you read boot --help ?
+ <youpi> iirc it's not a problem, both will receive all frames
+ <gnu_srs> yes I did
+ <youpi> then I don't see where you took device_file from
+ <youpi> at least in that form
+ <youpi> --device=device_name=device_file
+ <youpi> that means rather something like --device=foo=bar
+ <gnu_srs> so -f /dev/eth0 is correct usage then?
+ <youpi> didn't you see that in what I wrote, there was a "=" in there?
+ <gnu_srs> -f is the short option, --device is the long, I don't see the
+ need for = in the short option?
+ <youpi> in the long option there are *two* =
+ <gnu_srs> yes, but in the short no?
+ <youpi> why not?
+ <youpi> long -> short usually drops one =
+ <gnu_srs> to summarize: -f=/dev/eth0 or --device=eth_sub=/dev/eth0?
+ <youpi> why shouldn't there be a eth_sub in the short version?
+ <gnu_srs> 10:15:49) youpi: long -> short usually drops one =
+ <youpi> yes, it drops the =
+ <youpi> but nothing else
+ <youpi> if the long option needs some information, the short needs it too?
+ <youpi> -?
+ <gnu_srs> correct now? -f eth_sub=/dev/eth0 or --device=eth_sub=/dev/eth0?
+ <youpi> yes
+ <gnu_srs> k!
# Further Info
Read about using a subhurd for [[debugging_purposes|debugging/subhurd]].
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 37dac794..da141dc2 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -92,16 +92,19 @@ The [[concept|concepts]] of translators creates its own problems, too:
* [[exec]]
* [[proc]]
* [[pfinet]]
+* [[eth-filter]]
* [[pflocal]]
* [[hostmux]]
* [[storeio]]
* [[ext2fs]]
* [[fatfs]]
+* [[ufs]]
* [[magic]]
* [[unionfs]]
* [[nfs]]
* [[symlink]]
* [[firmlink]]
+* [[fifo]]
* ...
@@ -124,7 +127,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
*These Translators are available in the [hurdextras repository]( but not yet described on this website. They are in varying stages of Development.*
* [jfs](
-* [httpfs](
+* [[httpfs]]
* [memfs](
* [notice](
* [pith](
diff --git a/hurd/translator/eth-filter.mdwn b/hurd/translator/eth-filter.mdwn
new file mode 100644
index 00000000..4f59b402
--- /dev/null
+++ b/hurd/translator/eth-filter.mdwn
@@ -0,0 +1,26 @@
+[[!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
+# IRC, freenode, #hurd, 2013-07-27
+[[!tag open_issue_hurd]]
+ <youpi> ok, so as usual we actually *already* have a firewall
+ <youpi> it's the eth-filter translator from zheng da
+ <youpi> it has just never been really pushed forward...
+ <teythoon> good news :)
+ <youpi> well, the bad news is that it probably doesn't support connection
+ tracking
+ <youpi> since it's just bpf
+ <youpi> using the libpcap syntax
+ <teythoon> well, a stateless fw should do for Debian/Hurds needs for now,
+ right?
+ <youpi> yes
+ <youpi> and it does work indeed
diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn
index 867d4935..4947808e 100644
--- a/hurd/translator/examples.mdwn
+++ b/hurd/translator/examples.mdwn
@@ -16,7 +16,7 @@ or [hurd-extras](
cvs -z3 co <modulename>
-* httpfs translator
+* [[httpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -28,7 +28,7 @@ or
$ cd tmp/
$ ls -l
-* ftpfs translator
+* [[ftpfs]] translator
<!-- Prevent ikiwiki / Markdown rendering bug. -->
@@ -67,13 +67,13 @@ This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's
$ settrans -fgca /servers/socket/2 /hurd/pfinet -i <interface> -a <ip address> -m <subnet mask> -g <gateway ip>
-* Console translator -- setting up virtual consoles
+* [[Console]] translator -- setting up virtual consoles
<!-- Prevent ikiwiki / Markdown rendering bug. -->
$ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs
-* iso9660fs translator -- 'mounting' your cdrom
+* [[iso9660fs]] translator -- 'mounting' your cdrom
<!-- Prevent ikiwiki / Markdown rendering bug. -->
diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn
index 54abba7e..1dc0ea26 100644
--- a/hurd/translator/exec.mdwn
+++ b/hurd/translator/exec.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -11,4 +12,9 @@ License|/fdl]]."]]"""]]
The *exec* server, listening on `/servers/exec`, is responsible for
preparing the execution of processes.
+# Open Issues
+ * [[open_issues/exec]].
* [[open_issues/exec_memory_leaks]].
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 20faed5e..e2f6b044 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -179,6 +179,69 @@ small backend stores, like floppy devices.
That would be a nice improvement, but only after writeback throttling is implemented.
+## Stripped vs. Unstripped `ext2fs.static`
+[[!tag open_issue_hurd]]
+### IRC, freenode, #hurd, 2013-09-17
+ <teythoon> I always had some trouble with dropping a rebuild ext2fs.static
+ into my test system and I never figured out why
+ <teythoon> I just followed a hunch and stripped the binary, and all of the
+ sudden it works
+ <teythoon> any ideas why?
+ <tschwinge> teythoon: I quick search found me:
+ <> and
+ <>.
+ <teythoon> tschwinge: ugh, thanks for the pointers ;)
+ <tschwinge> teythoon: They won't help too much I fear. Anyway, good
+ intuition (or whatever) ;-) that you found this out.
+ <tschwinge> teythoon: Not exactly related to stripped/unstripped per se
+ (that is, debug information), but in the past we've had an issue about
+ relro (see binutils/glibc, <>),
+ where a variable (that erroneously happend to be in such a read-only
+ section, if I remember correct) was tried to be modified -- which worked
+ "sometimes": depending on where exactly it was located in the binary
+ (which shifted around a page
+ <tschwinge> boundary by stripped/unstripped), it'd segfault or not. Burnt
+ several days on that before Samuel (IIRC) eventually figured it out.
+ <teythoon> tschwinge: well, thanks anyway ;)
+## Increased Memory Consumption
+### IRC, freenode, #hurd, 2013-09-18
+ <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+ last updated the hurd package :/
+ <braunr> i wonder if my ext2fs large store patches rework have introduced a
+ regression
+ <braunr> the order of magnitude here is around 1.5G virtual space :/
+ <braunr> it used to take up to 3 times less before that
+ <braunr> looks like my patches didn't make it into the latest hurd package
+ <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+ <teythoon> :/
+ <braunr> memory only
+ <braunr> the number of ports looks stable relative to file system usage
+ <teythoon> braunr: I tested my patches on my development machine, it's up
+ for 14 days (yay libvirt :) and never encountered problems like this
+ <braunr> i've been building glibc to reach that state
+ <teythoon> hm, that's a heavy load indeed
+ <teythoon> could be the file name tracking stuff, I tried to make sure that
+ everything is freed, but I might have missed something
+ <braunr> teythoon: simply running htop run shows a slight, regular increase
+ in physical memory usage in ext2fs
+ <pinotree> old procfs stikes again? :)
+ <teythoon> braunr: I see that as well... curious...
+ <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+ to make sure that everything is freed, but I might have missed something
+ <braunr> how knows, maybe completely unrelated
+ <teythoon> the tracking patch isn't that big, I've gone over it twice today
+ and it still seems reasonable to me
+ <braunr> hm
# Documentation
* <>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
new file mode 100644
index 00000000..857922fc
--- /dev/null
+++ b/hurd/translator/fifo.mdwn
@@ -0,0 +1,48 @@
+[[!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
+The *fifo* translator implements named pipes (FIFOs).
+# Open Issues
+## Not Terminating
+[[!tag open_issue_hurd]]
+### IRC, OFTC, #debian-hurd, 2013-07-28
+ <gg0> seems fifos started dying, as they should. am i wrong?
+ <gg0> ( )
+ <azeem> so you're saying the bug should be closed?
+ <azeem> best to comment on the bug then
+ <gg0> i didn't hear anyone working on it, so i'm a bit surprised
+ <azeem> could be due to lower-level fixes to glibc or so
+ <gg0> and given often(:|) i'm wrong, i was asking
+ <pinotree> in two years there have been various changes in glibc and hurd
+ <pinotree> (for example the switch to pthreads)
+ <gg0> yeah seems fixed. mknod'ing one then removing it, doesn't leave any
+ process around
+ <gg0> cool
+ <azeem> then please follow-up on the bug and/or close it
+ <gg0> sure
+ <gg0> the pleasure of closing it/them is yours
+ <gg0> great job, whatever you did :)
+### IRC, OFTC, #debian-hurd, 2013-07-29
+ * gg0 wonders if it can close savannah one as
+ well
+ <pochu> gg0: wdym?
+ <pochu> gg0: got an example?
+ <gg0>
+ <gg0> i didn't close it myself
diff --git a/hurd/translator/hostmux.mdwn b/hurd/translator/hostmux.mdwn
index 5fab2dc5..ef16505b 100644
--- a/hurd/translator/hostmux.mdwn
+++ b/hurd/translator/hostmux.mdwn
@@ -29,3 +29,18 @@ When <code>**/ftp**</code> is accessed, the first directory is interpreted as ho
You can see the new created translator in the process list: <code>**ps ax | grep ftpsfs**</code> . You shoud see <code>**/hurd/ftpfs /**</code> .
-- [[Main/PatrickStrasser]] - 13 Jul 2004
+# Open Issues
+## IRC, freenode, #hurd, 2013-09-21
+[[!tag open_issue_hurd]]
+ <jproulx> ls /http://<ip>:<port>/
+ <jproulx> the image came with a global translator though I see it doesn't
+ grokk the alternate port notation.
+ <youpi> oh right
+ <jproulx> I shall return to the fine documentation
+ <youpi> it's a hostmux, it doesn't understand ports
+ <youpi> damn, one thus can't url plain urls with that scheme
diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
new file mode 100644
index 00000000..dc4a62f7
--- /dev/null
+++ b/hurd/translator/httpfs.mdwn
@@ -0,0 +1,100 @@
+[[!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
+`httpfs` is a virtual filesystem allowing you to access web pages and files.
+# Source
+# Documentation
+## IRC, freenode, #hurd, 2013-09-03
+[[!tag open_issue_documentation]]
+ <congzhang> hi, why I can't cd to /http:/ to do
+ <congzhang> grep?
+ <pinotree> this is not ftp
+ <congzhang> it works for other file
+ <pinotree> ?
+ <congzhang> I can't cd to ~larstiq, I don't know why
+ <pinotree> http is not a filesystem protocol
+ <pinotree> while httpfs could try in representing it as such, it is not
+ something reliable
+ <congzhang> ok, it's not reliable
+ <congzhang> I expect it can expose dir like browser
+ <congzhang> so, the translator just know href from home page, and one by
+ one
+ <pinotree> uh?
+ <congzhang> if ...:80/a/b/c.png exits, but not has a href in homepage, so I
+ can't cd to a, right?
+ <pinotree> you are looking things from the wrong point of view
+ <pinotree> a web server can do anything with URLs, including redirecting,
+ URL rewriting and whatever else
+ <congzhang> so, how to understand httpfs's idea?
+ <congzhang> how httpfs list dir?
+ <pinotree> check its code
+ <congzhang> en, no need it's not reliable
+ <congzhang> it's not work, it's enough
+ <congzhang> I have an idea, for the file system, we explore dir level by
+ level, but for http, we change full path one
+ <congzhang> once time
+ <congzhang> maybe can allow user to cd any directory, and just mark as some
+ special color to make user know the translator was not sure, file exist
+ or not
+ <congzhang> once the file exits, mark all the parent directory as normal
+ color?
+ <rekado> congzhang: you can find more info about httpfs here:
+ <pinotree> congzhang: you're still looking at http from the wrong point of
+ view
+ <pinotree> there are no directories nor files
+ <pinotree> you start a request for a URL, and you get some content back (in
+ case there's no error)
+ <congzhang> you mean httpfs just for kidding?
+ <pinotree> that the content is a web page listing a directory on the
+ filesystem of the web server machine, or a file sent back via the
+ connection, or a complex web page, it's the same
+ <rekado> congzhang: you can only get a list of files if the web server
+ responds with an index of files
+ <pinotree> "files"
+ <rekado> The readme explains how httpfs does its thing:
+ <congzhang> if I can't cd to /http:/host/a/b how to get
+ /http:/host/a/b/c.html, even the file exist?
+ <pinotree> you don't cd in http
+ <pinotree> cd is for changing directory, which does not apply to a protocol
+ like http which is not fs-oriented
+ <congzhang> yes, I agree with you, http was not fs-oriented
+ <congzhang> so httpfs was not so useful
+ <rekado> You can access the document directly, though, can't you?
+ <congzhang> rekado: I try once more
+ <congzhang> I can't
+ <congzhang> so, the httpfs need some extend, http protocol was not fs
+ oriented, so need some extend to make it work with file system
+ <pinotree> http is not designed for file system usage, so extending it is
+ useless
+ <congzhang> or, httpfs was not so useful
+ <pinotree> there are many other protocols for file systems
+ <congzhang> I don't think so
+ <pinotree> i do
+ <congzhang> if we can't make it more useful, remove it from hurd rep, or
+ extend it more useful
+ <congzhang> add some more rule, to make it work with file system
+ <pinotree> no
+ <congzhang> some paradox in it
+ <pinotree> which paradox?
+ <congzhang> for http vs file system
+ <pinotree> ???
+ <congzhang> tree oriented and star topology oriented?
+ <pinotree> you don't make any sense
diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn
index d156772b..6b3be79c 100644
--- a/hurd/translator/nsmux.mdwn
+++ b/hurd/translator/nsmux.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
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
# nsmux
@@ -119,3 +119,24 @@ of the simplest use-case of namespace-based translator selection in
the form of translator `nsmux`. The filter is partially implemented
and this is the immediate goal. Propagating translators down
directories is the next objective.
+## Open Issues
+### IRC, freenode, #hurd, 2013-08-22
+[[!tag open_issue_hurd]]
+ < youpi> err, is nsmux supposed to work at all?
+ < youpi> a mere ls doesn't work
+ < youpi> I'm running it as a user
+ < youpi> echo * does work though
+ < teythoon> ah, yes, nsmux,,is,,funny :p
+ < youpi> well, perhaps but I can't make it work
+ < youpi> well, the trivial ,,hello does work
+ < youpi> but ,,tarfs doesn't seem to be working for instance
+ < youpi> same for ,,mboxfs
+ < youpi> ,,xmlfs seems to somehow work a bit, but not very far...
+ < youpi> so it seems just nobody is caring about putting READMEs wherever
+ appropriate
+ < youpi> e.g. examples in socketio/ ...
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index f6f69ea4..bf535b21 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 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
@@ -33,6 +33,9 @@ installation.
* [[DHCP]].
+ * [[IPv6]].
+ * [[eth-filter]]: Firewall.
* [[Implementation]].
- * [[IPv6]].
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 9bcf62ef..2361615a 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,6 +27,170 @@ implementation.
<youpi> oh
+## IRC, freenode, #hurd, 2013-09-03
+In context of the item on [[/contributing]].
+ <rekado> About this task: "Make pfinet OK with the ethernet device going
+ away." --- how can I test this? How can I remove the ethernet device?
+ <pinotree> settrans on the ethernet device, handled by the netdde
+ translator
+ <pinotree> that is, make it go away (settrans -fg)
+ <rekado> Ah, I see.
+ <rekado> Thanks
+ <pinotree> check its status before with showtrans
+ <pinotree> then, after having made it go away, set it again
+ <rekado> I don't think I'm doing this right... After `settrans -fg
+ /dev/eth0` I should not be able to access the network anymore, but it
+ still works.
+ <rekado> How can I figure out which of the four network devices is actually
+ used?
+ <braunr> rekado: the file system is used to open files, i.e. access
+ services
+ <braunr> it's not used to revoke access
+ <braunr> once pfinet has obtained a port to the network device, it keeps it
+ <rekado> oh, yes, of course. Sorry, this is all very
+ new to me.
+ <rekado> I'm not sure what the problem is that this task describes. In
+ what way is pfinet "not OK" with the ethernet device going away?
+ <braunr> rekado: the idea is to make pfinet able to cope with a driver
+ crash
+ <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
+ build a purposefully broken driver first?)
+ <braunr> use kill
+ <rekado> Oh, good.
+ <braunr> iirc, netdde doesn't restart correctly :x
+ <braunr> you'll probably have to fix it a bit
+ <braunr> i guess there is some persistent state that prevents it from
+ reinitializing correctly
+ <rekado> okay
+ <rekado> I may need one more pointer: where can I find the netdde code?
+ Grep'ing around I only see it only mentioned as an argument to
+ /hurd/devnode; also: should I work in some incubator branch or directly
+ in the hurd repo?
+ <braunr> rekado: incubator branch
+ <rekado> Okay. Thank you for your patience. I'll play with this in the
+ next few days.
+ <braunr> enjoy
+ <rekado> :)
+### IRC, freenode, #hurd, 2013-09-05
+ <rekado> When I kill the /hurd/netdde process I can no longer access the
+ network (as expected);
+ <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
+ /dev/netdde eth0" from the /dev directory.
+ <rekado> When I access the network again everything is fine. (I do see a
+ message telling me "irq handler 11: release an dead delivery port"
+ <rekado> )
+ <rekado> Is it the goal to avoid having to run settrans again to run netdde
+ after it crashes or is killed?
+ <youpi> you don't need to run settrans again
+ <youpi> that should get triggered automatically
+ <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
+ <rekado> It doesn't seem to be restarted automatically.
+ <youpi> try again
+ <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
+ <youpi> the second wil respawn pfinet
+ <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
+ "contributing page"
+ <rekado> Ah, so that's what should be prevented.
+ <youpi> it's just a matter of making pfinet be fine with errors from the
+ eth translator, and simply reopen it instead of dying
+ <rekado> That's the thing I've been trying to figure out.
+ <rekado> when I run wget a second (or third) time I get a different error;
+ "Name or service not known."
+ <rekado> It's only okay again when I use settrans
+ <youpi> maybe the devnode translator also needs some fixing
+ <youpi> it's odd that I don't have the issue though
+ <rekado> I'm using the qemu image, updated just yesterday.
+ <youpi> same here
+ <youpi> anyway, now you know where to put your hands :)
+ <rekado> yes, thanks a lot.
+### IRC, freenode, #hurd, 2013-09-07
+ <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
+ edev->ether_port == MACH_PORT_NULL
+ <rekado> This is violated when netdde was killed and the device is
+ reopened.
+ <rekado> I'm not sure what should be done: destroy the port before
+ reopening or drop the assertion?
+ <rekado> If I drop the assertion, Mach seems to handle this just fine.
+ <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
+ then carries on without problems.
+ <rekado> Is this a warning or an error, or can this be ignored?
+ <rekado> (or none of the above?)
+### IRC, freenode, #hurd, 2013-09-08
+ <rekado> I have a simple patch for pfinet that lets it recover from an
+ error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
+ killed.
+ <rekado> It doesn't work, though, when only netdde has been killed.
+ <rekado> With devnode still around device_open fails with "(ipc/send)
+ invalid destination port"
+ <rekado> I don't know where device_open is defined and why this error is
+ returned.
+ <rekado> I guess the error refers to the "master_device" port returned by
+ file_name_lookup() in ethernet_open()
+ <rekado> Why would file_name_lookup() return an invalid port when netdde is
+ dead but devnode is still running?
+ <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
+ well
+### IRC, freenode, #hurd, 2013-09-09
+ <rekado> braunr: re devnode: devnode only performs a single lookup in
+ parse_opt(), i.e. at start-up.
+ <rekado> I'll try to understand devnode enough to patch it.
+ <braunr> rekado: that's the problem
+ <braunr> it should perform a lookup every time it's opened
+[[!message-id ""]],
+[[!message-id ""]].
+ <rekado> I submitted two patches to the mailing list. I've tested them on
+ Debian GNU/Hurd but based them on the incubator/dde branch.
+ <teythoon> rekado: awesome, reliability fixes are very much welcome
+### IRC, freenode, #hurd, 2013-09-18
+ <rekado> youpi: my apologies for the delay in getting back to you with
+ improvements to my pfinet/devnode patches. Been very busy.
+ <braunr> rekado: development pace on the hurd has always been slow, no need
+ to apologize
+## MAC Addresses
+[[!tag open_issue_hurd]]
+### IRC, freenode, #hurd, 2013-09-21
+ <jproulx> what command will show me the MAC address of an interface?
+ <youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
+ <youpi> I don't think we already have a tool for that
+ <youpi> it would be a matter of patching inetutils-ifconfig
+## Routing Tables
+[[!tag open_issue_hurd]]
+### IRC, freenode, #hurd, 2013-09-21
+ <jproulx> Hmmm, OK I can work around that, what about routing tables, can I
+ see them? can I add routes besides the pfinet -g default route?
+ <youpi> I don't think there is a tool for that yet
+ <youpi> it's not plugged inside pfinet anyway
# Reimplementation, [[!GNU_Savannah_task 5469]]
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index dc2434dc..fdcc39f1 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,13 +1,35 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation,
[[!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
The implementation of the `pflocal` server is in the `pflocal` directory, and
uses [[`libpipe`|libpipe]] (shared code with the [[named_pipe|fifo]]
+# Open Issues
+### IRC, freenode, #hurd, 2013-09-19
+ <gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two
+ entries:
+ <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality
+ seems to be unimplemented.
+ <pinotree> gnu_srs: pfinet supports it
+ <youpi> gnu_srs: grep talks about pfinet/linux-src/net/core/sock.c:
+ <youpi> two times
+ <gnu_srs> Yes, and that is the implementation?
+ <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX
+ (maybe not so interesting case).
+ <pinotree> pflocal does not support it
+ <gnu_srs> Is that of interest at all?
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
index 98940f87..d5e0960c 100644
--- a/hurd/translator/proc.mdwn
+++ b/hurd/translator/proc.mdwn
@@ -51,3 +51,25 @@ It is stated by `/hurd/init`.
it could just exec sysvinit
<teythoon> I just think it's easier to patch hurd than to remove the
assumption that init is pid 1 from sysvinit
+## IRC, freenode, #hurd, 2013-09-13
+ <braunr> teythoon: also, as a feature request, i'd like the proc server not
+ to have pid 0, if you have any time to do that
+ <braunr> so it appears in top and friends
+ <teythoon> braunr: noted, that should be easy
+ <teythoon> not using 0 is probably a good thing, many things use pid 0 as
+ something special
+# Process Discovery
+## IRC, freenode, #hurd, 2013-08-26
+ < teythoon> somewhat related, I do not like the way the proc server just
+ creates processes for new mach tasks it discovers
+ < teythoon> that does not play well with subhurds for example
+ < braunr> teythoon: i agree with you on proc process-to-task mapping
+ < braunr> that's something i intend to completely rework on propel
+ < braunr> in a way similar to how pid namespaces work on linux
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index fcda453e..44b8cc77 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -150,6 +150,9 @@ License|/fdl]]."]]"""]]
<youpi> it "just" needs to be commited :)
<antrik> in either case, it can't hurt to bring this up again :-)
+[[community/gsoc/project_ideas/mtab/discussion]], *IRC, freenode, #hurd,
# root group
@@ -305,6 +308,13 @@ License|/fdl]]."]]"""]]
See also [[community/gsoc/project_ideas/mtab]].
+## IRC, freenode, #hurd, 2013-09-20
+ <pinotree> teythoon: should procfs now have $pid/mounts files pointing to
+ ../mounts?
+ <teythoon> pinotree: probably yes
# `/proc/[PID]/auxv`
Needed by glibc's `pldd` tool (commit
diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn
new file mode 100644
index 00000000..4d611e95
--- /dev/null
+++ b/hurd/translator/ufs.mdwn
@@ -0,0 +1,38 @@
+[[!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
+The `ufs` translator supports some kind of the Unix File System. Beware, we're
+not aware of anybody having used/tested it in ages, so maybe it is very broken
+and will eat your data.
+# IRC, freenode, #hurd, 2013-08-30
+[[!tag open_issue_hurd]]
+ <Arne`> There might be a copyright problem: <nalaginrut> well, there seems
+ BSD-4clauses in the code:
+ <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and
+ GPL on the same code are a license incompatibility…
+ <tschwinge> Arne`: I've put it onto my (long) TODO list.
+ <tschwinge> Easiest solution might be: rm -rf ufs.
+ <nalaginrut> will these affected code rewritten? or just modify license?
+ <mark_weaver> only the regents of the University of California could choose
+ to modify the license.
+ <youpi> nalaginrut: one can't modify a licence if one is not the author
+ <youpi> we can simply dump the code
+ <mark_weaver> s/author/owner/
+ <tschwinge> As I suppose ufs is unused/untested for a decade or so, I'd
+ have no issues with simply removing it from the tree, together with
+ ufs-fsck and ufs-utils.
+ <pinotree> tschwinge: or maybe extract the ufs stuff in an own repo, to be
+ imported as branch in incubator or own hurd/ufs.git?
+ <tschwinge> Sure, why not.
diff --git a/libpthread.mdwn b/libpthread.mdwn
index fc5c0974..0f7f28fe 100644
--- a/libpthread.mdwn
+++ b/libpthread.mdwn
@@ -61,7 +61,7 @@ even if the current number of threads is lower.
The same issue exists in [[hurd/libthreads]].
The current implementation in libpthread is
# Open Issues
diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn
index a5a73e18..f5626f6c 100644
--- a/microkernel/discussion.mdwn
+++ b/microkernel/discussion.mdwn
@@ -10,7 +10,7 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_documentation]]
-IRC, freenode, #hurd, 2011-07-26:
+# IRC, freenode, #hurd, 2011-07-26
< antrik> Tekk_`: regarding microkernels: the basic idea, and really the
*only* fundamental difference, is that they isolate things in separate
@@ -22,3 +22,41 @@ IRC, freenode, #hurd, 2011-07-26:
these are secondary effects: such choices can also be implemented in a
monolithic architecture -- and not necessarily harder. just less obvious
in some cases...
+# IRC, freenode, #hurd, 2013-08-28
+ <Spyro> ok question
+ <Spyro> what is the big advantage of microkernels over monolithic kernels
+ as you guys see it?
+ <Spyro> is it entirely for the benefit of developers or are there actaully
+ practical advantages?
+ <kilobug> Spyro: there are many advantages, at least in theory, in terms of
+ modularity, flexibility, stability, scalability, security, ... which are
+ for everyone
+ <braunr> Spyro: of course some advantages are practical
+ <braunr> for me, the main advantage is system extensibility
+ <braunr> you can replace system services at runtime
+ <braunr> and on the hurd, you can do it as an unprivileged user
+ <braunr> (the direct side effect is far increased security)
+ <braunr> kilobug: i don't see the scalability advantages though
+ <kilobug> braunr: I would say it goes in par with the modularity, like, you
+ can have a full-weight IPv4/IPv6 stack for desktop, but a minimal stack
+ for embeded
+ <braunr> i see
+ <braunr> for me, it's in par with extensibility :)
+ <braunr> i see modularity only as an implementation of extensibility
+ <braunr> or a special case of it
+ <braunr> Spyro: basically, it's supposed to bring the same advantages as
+ fuse, but even more so (because it's not limited to file systems), and
+ better (because it's normally well integrated with the core of the
+ system)
+ <teythoon> also, fuse is kind of bolted on and Linux composes really badly
+ <teythoon> e.g. it is not possible to nfs export a fuse mounted filesystem
+ on Linux
+ <braunr> bolted ?
+ <teythoon> isn't that the term? as in being attached using screws?
+ <braunr> i'm not familiar with it :p
+ <azeem> "a posteriori design"
+ <teythoon> yes
+ <braunr> ok
diff --git a/microkernel/l4.mdwn b/microkernel/l4.mdwn
index de311497..ef39616b 100644
--- a/microkernel/l4.mdwn
+++ b/microkernel/l4.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011, 2012 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 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
@@ -30,6 +30,14 @@ is now stalled.
Genode and L4:
+# IRC, freenode, #hurd, 2013-08-26
+ < Spyro> also
+ < Spyro> what's the basic difference between mach and L4?
+ < braunr> l4 is a nanokernel whereas mach is a hybrid with high level
+ messaging and virtual memory services
[[!ymlfront data="""
diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn
index 0f7cbf00..08bce3f5 100644
--- a/microkernel/mach/concepts.mdwn
+++ b/microkernel/mach/concepts.mdwn
@@ -31,3 +31,20 @@ text="*[[mach\_kernel\_principles|documentation]]*:
In particular the [[!toggle id=mach_kernel_principles
text="[mach\_kernel\_principles]"]] book further elaborates on Mach's concepts
and principles.
+# IRC, freenode, #hurd, 2013-08-26
+ < stargater> then is mach not more microkernel
+ < stargater> when it have driver inside
+ < braunr> mach is a hybrid
+ < braunr> even without drivers
+ < stargater> in www i read mach is microkernel
+ < stargater> not hybrid
+ < braunr> the word microkernel usually includes hybrids
+ < braunr> true microkernels are also called nanokernels
+ < braunr> the word isn't that important, what matters is that mach does
+ more in kernel than what the microkernel principle implies
+ < braunr> e.g. high level async IPC and high level virtual memory
+ operations
+ < braunr> including physical memory management
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index 03e4a8b0..8f47f61f 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -2318,3 +2318,69 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
about them
<braunr> even with that, it should be scalable enough for a start
<braunr> and improving those parts shouldn't be too difficult
+## IRC, freenode, #hurd, 2013-07-10
+ <nlightnfotis> braunr: From what I have understood you aim for x15 to be a
+ production ready μ-kernel for usage in the Hurd? Or is it unrelated to
+ the Hurd?
+ <braunr> nlightnfotis: it's for a hurd clone
+ <nlightnfotis> braunr: I see. Is it close to any of the existing
+ microkernels as far as its design is concerned (L4, Viengoos) or is it
+ new research?
+ <braunr> it's close to mach
+ <braunr> and qnx
+## IRC, freenode, #hurd, 2013-07-29
+ <braunr> making progress on x15 pmap module
+ <braunr> factoring code for mapping creation/removal on current/kernel and
+ remote processes
+ <braunr> also started "swap emulation" by reserving some physical memory to
+ act as swap backing store
+ <braunr> which will allow creating memory pressure very early in the
+ development process
+## IRC, freenode, #hurd, 2013-08-23
+ < nlightnfotis> braunr: something a little bit irrelevant: how many things
+ are missing from mach to be considered a solid base for the Hurd? Is it
+ only SMP and x86_64 support?
+ < braunr> define "solid base for the hurd"
+ < nlightnfotis> solid enough to not look for a replacement for it
+ < braunr> then i'd say, from my very personal point of view, that you want
+ x15
+ < nlightnfotis> I didn't understand this. Are you planning for x15 to be a
+ better mach?
+ < braunr> with a different interface, so not compatible
+ < braunr> and thus, not mach
+ < nlightnfotis> is the source code for it available? Can I read it
+ somewhere?
+ < braunr> the implied answer being: no, mach isn't a solid base for the
+ hurd considering your definition
+ < braunr>
+ < nlightnfotis> thanks. for that. So it's definite that mach won't stay for
+ long as the Hurd's base, right?
+ < braunr> it will, for long
+ < braunr> my opinion is that it needs to be replaced
+ < nlightnfotis> is it possible that it (slowly) gets rearchitected into
+ what's being considered a second generation microkernel, or is it
+ hopeless?
+ < braunr> it would require a new interface
+ < braunr> you can consider x15 to be a modern mach, with that new interface
+ < braunr> from a high level view, it's very similar (it's a hybrid, with
+ both scheduling and virtual memory management in the kernel)
+ < braunr> ipc change a lot
+## IRC, freenode, #hurd, 2013-09-23
+ <braunr> for those of us interested in x15 and scalability in general:
+ <braunr> finally an implementation allowing memory mapping to occur
+ concurrently
+ <braunr> (which is another contention issue when using mach-like ipc, which
+ often do need to allocate/release virtual memory)
diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn
index cc880ab6..61e3469b 100644
--- a/microkernel/mach/documentation.mdwn
+++ b/microkernel/mach/documentation.mdwn
@@ -1,5 +1,5 @@
[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-2010 Free Software Foundation, Inc."]]
+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
@@ -47,3 +47,14 @@ License|/fdl]]."]]"""]]
- [An IO System for Mach](
- [A Programmers' Guide to Mach System Call](
+# IRC, freenode, #hurd, 2013-09-15
+ <teythoon> braunr: btw, are there multiple kernel threads in gnumach?
+ <teythoon> and is it safe to do a synchronous rpc call to a userspace
+ server?
+ <braunr> teythoon: there are yes, but few
+ <braunr> teythoon: the main (perhaps only) kernel thread is the page daemon
+ <braunr> and no, it's not safe to do synchronous calls to userspace
+ <braunr> except to the default pager
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 587178e9..32e712c9 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -105,6 +105,11 @@ These boards are known to work. Gnumach/Hurd has been installed and run on these
* VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good.
* Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup.
* Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3.
+* IRC, freenode, #hurd, 2013-08-26:
+ < stargater> have anyone gnu/hurd running on real hw ?
+ < youpi> my latitude e6420 laptop, for instance
# User Failure Reports
diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn
index ea52904a..799ed5cc 100644
--- a/microkernel/mach/message/msgh_id.mdwn
+++ b/microkernel/mach/message/msgh_id.mdwn
@@ -13,6 +13,8 @@ License|/fdl]]."]]"""]]
Every [[message]] has an ID field, which is defined in the [[RPC]] `*.defs`
# IRC, freenode, #hurd, 2012-07-12
@@ -281,3 +283,25 @@ files.
<youpi> then submit to the list for review
<braunr> hm ok
<braunr> youpi: ok, next time, i'll commit such changes directly
+# Subsystems
+## IRC, freenode, #hurd, 2013-09-03
+ <teythoon> anything I need to be aware of if I want to add a new subsystem?
+ <teythoon> is there a convention for choosing the subsystem id?
+ <braunr> a subsystem takes 200 IDs
+ <braunr> grep other subsystems in mach and the hurd to avoid collisions of
+ course
+ <teythoon> yes
+ <teythoon> i know that ;)
+ <braunr> :)
+ <teythoon> i've noticed the _notify subsystems being x+500, should I follow
+ that?
+ <pinotree> 100 for rpc + 100 for their replies?
+ <braunr> teythoon: yes
+ <braunr> pinotree: yes
+ <teythoon> ok
+ <teythoon> we should really work on mig...
+ <braunr> ... :)
diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn
index d6340574..f8046cb2 100644
--- a/microkernel/mach/mig.mdwn
+++ b/microkernel/mach/mig.mdwn
@@ -24,7 +24,8 @@ them to the client program. Similar actions are provided in the skeletons that
are linked to server programs.
MIG allows very precise semantics to be specified about what the arguments are
and how to be passed.
-It has its problems with [[structured_data]], however.
+It has its problems with
+[[structured_data|open_issues/mig_portable_rpc_declarations]], however.
* [[Documentation]]
diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn
index 7d4f1eca..e6bd1bb9 100644
--- a/microkernel/mach/mig/documentation.mdwn
+++ b/microkernel/mach/mig/documentation.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 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
@@ -82,3 +82,20 @@ pp. 67--77."
* [[ServerCopy]]
* MIG *in action*: [[hurd/io_path]].
+## IRC, freenode, #hurd, 2013-09-04
+[[!tag open_issue_documentation open_issue_mig]]
+ <teythoon> btw, I just realized that mig mashes two very different things
+ together, namely the serialization/parsing and the message
+ sending/receiving
+ <braunr> yes
+ <teythoon> I'd prefer it if that were separated
+ <braunr> me too
+ <braunr> that's why i want x15 to have a bare messaging interface .. :)
+ <teythoon> \o/
+ <braunr> simple (but optimized) scatter-gather
+ <braunr> it makes sense for mig since mach messages do include
+ serialization metadata such as types
diff --git a/microkernel/mach/mig/structured_data.mdwn b/microkernel/mach/mig/structured_data.mdwn
deleted file mode 100644
index 1c8abe08..00000000
--- a/microkernel/mach/mig/structured_data.mdwn
+++ /dev/null
@@ -1,119 +0,0 @@
-[[!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
-[[!tag open_issue_mig]]
-# IRC, freenode, #hurd, 2013-06-25
- <teythoon> is there a nice way to get structured data through mig that I
- haven't found yet?
- <teythoon> say an array of string triples
- <braunr> no
- <teythoon> :/
- <braunr> but you shouldn't need that
- <teythoon> my use case is getting info about fs translators from init to
- procfs
- <teythoon> should I go for an iterator like interface instead?
- <braunr> depends
- <braunr> how many do you need ?
- <braunr> you could go for a variable sized array too
- <braunr> have a look at what already exists
- <teythoon> records, maybe 10-15, depends on many fs translators are running
- <braunr> a variable sized array is ok if the size isn't too big (and when i
- say too big, i mean hundreds of MiB)
- <braunr> an iterator is ok too if there aren't too many items
- <braunr> you may want to combine both (i think that's what proc does)
- <braunr> be aware that the maximum size of a message is limited to 512 MiB
- <teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
- does not work, I guess b/c string_t is also an array
- <teythoon> how would I send an array of variable length strings?
- <braunr> i'm not sure you can
- <braunr> or maybe out of line
- <teythoon> somehow I expected mig to serialize arbitrary data structures,
- maybe it's to old for that?
- <teythoon> yeah, I read about uot of line, but that seems overkill
- <braunr> it is old yes
- <braunr> and not very user friendly in the end
- <braunr> let me check
- <teythoon> we could stuff json into mig...
- <braunr> see proc_getallpids for example
- <braunr> we could get rid of low level serialization altogether :p
- <teythoon> hah, exactly what I was looking at
- <braunr> (which is what i'll do in x15)
- <braunr> type pidarray_t = array[] of pid_t;
- <teythoon> but that is trivial b/c its array[] of pid_t
- <braunr> and always have the server writing guide near you
- <teythoon> yes
- <braunr> well, make one big string and an array of lengths :p
- <teythoon> thought about that and said to myself, there must be a better
- way that I haven't found yet
- <braunr> or one big string filled with real null-terminated c strings that
- you keep parsing until you ate all input bytes
- <braunr> i'm almost certain there isn't
- <braunr> type string_t = c_string[1024]; /* XXX */
- <teythoon> yes
- <braunr> even that isn't really variable sized
- <teythoon> you think anyone would object to me putting a json encoder in
- /hurd/init? it is probably better than me at serializing stuff...
- <braunr> try with mig anyway
- <braunr> the less dependencies we have for core stuff, the simpler it is
- <braunr> but i agree, mig is painful
- <teythoon> would it be too hacky if I abused the argz functions? they do
- exactly what I'd need
-## IRC, freenode, #hurd, 2013-06-26
- <teythoon> there is and it has a rpc
- mechanism and I believe one could plug arbitrary transports easily
- <braunr> please don't think about it
- <braunr> we really don't want to add another layer of serialization
- <braunr> it's better to completely redesign mach ipc anyway
- <braunr> and there is a project for that :p
- <teythoon> ive seen x15
- <teythoon> just food for thought
- <braunr> i've studied google protocol buffers
- <braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
- top of mach
- <braunr> there is a lot of knowledge about mach ports in mig
- <teythoon> but again I face the challenge of serializing a arbitrary sized
- list of arbitrary sized strings
- <braunr> yes
- <teythoon> list of ports is easier ;) but I think its worthwile
- <teythoon> so what about abusing argz* for this? you think it's too bad a
- hack?
- <braunr> no since it's in glibc
- <teythoon> awesome :)
- <braunr> but i don't remember the details well and i'm not sure the way you
- use it is safe
- <teythoon> yeah, I might have got the details wrong, I hadn't had the
- chance to test it ;)
- <braunr> about this dynamic size problem
- <braunr> a "simple" varying size array should do
- <braunr> you can easily put all your strings in there
- <teythoon> seperated by 0?
- <braunr> yes
- <teythoon> that's exactly what the argz stuff does
- <braunr> you'll get the size of the array anyway, and consume it until
- there is no byte left
- <braunr> good
- <braunr> but be careful with this too
- <braunr> since translators can be run by users, they somtimes can't be
- trusted
- <braunr> and even a translator running as root may behave badly
- <braunr> so careful with parsing
- <teythoon> noted
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 75a62535..ba72b00f 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -660,3 +660,146 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
<braunr> but as youpi said, it still requires work
<braunr> and nobody's working on it
<braunr> you may want to check l4 fiasco.oc though
+# System Personality
+## IRC, freenode, #hurd, 2013-07-29
+ <teythoon> over the past few days I gained a new understanding of the Hurd
+ <braunr> teythoon: really ? :)
+ <tschwinge> teythoon: That it's a complex and distributed system? ;-)
+ <tschwinge> And at the same time a really simple one?
+ <tschwinge> ;-D
+ <teythoon> it's just a bunch of mach programs and some do communicate and
+ behave in a way a posix system would, but that is more a convention than
+ anything else
+ <teythoon> tschwinge: yes, kind of simple and complex :)
+ <braunr> the right terminology is "system personality"
+ <braunr> 11:03 < teythoon> over the past few days I gained a new
+ understanding of the Hurd
+ <braunr> teythoon: still no answer on that :)
+ <teythoon> braunr: ah, I spent lot's of time with the core servers and
+ early bootstrapping and now I gained the feeling that I've seen the Hurd
+ for what it really is for the first time
+# RPC Interfaces
+## IRC, freenode, #hurd, 2013-09-03
+ <rekado> I'm a little confused by the hurd and incubator git repos.
+ <rekado> DDE is only found in the dde branch in incubator, but not in the
+ hurd repo.
+ <rekado> Does this mean that DDE is not ready for master yet?
+ <braunr> yes
+ <rekado> If DDE is not yet used in the hurd (except in the dde branch in
+ the incubator repo), does pfinet use some custom glue code to use the
+ Linux drivers?
+ <braunr> this has nothing to do with pfinet
+ <braunr> pfinet is the networking stack, netdde are the networking drivers
+ <braunr> the interface between them doesn't change, whether drivers are in
+ kernel or not
+ <rekado> I see
+# IRC, freenode, #hurd, 2013-09-20
+ <giuscri> HI there, I have no previous knowledge about OS's. I'm trying to
+ undestand the structure of the Hurd and the comparison between, say,
+ Linux way of managing stuff ...
+ <giuscri> for instance, I read: "Unlike other popular kernel software, the
+ Hurd has an object-oriented structure that allows it to evolve without
+ compromising its design."
+ <giuscri> that means that while for adding feature to the Linux-kernel you
+ have to add some stuff `inside` a procedure, whilst in the Hurd kernel
+ you can just, in principle at least, add an object and making the kernel
+ using it?...
+ <giuscri> Am I making stuff too simple?
+ <giuscri> Thanks
+ <braunr> not exactly
+ <braunr> unix historically has a "file-oriented" structure
+ <braunr> the hurd allows servers to implement whatever type they want,
+ through the ability to create custom interfaces
+ <braunr> custom interfaces means custom calls, custom semantics, custom
+ methods on objects
+ <braunr> you're not restricted to the set of file interfaces (open, seek,
+ read, write, select, close, etc..) that unix normally provides
+ <giuscri> braunr: uhm ...some example?
+ <braunr> see processes for example
+ <braunr> see
+ <braunr> this is the collection of interfaces the hurd provides
+ <braunr> most of them map to unix calls, because gnu aims at posix
+ compatibility too
+ <braunr> some are internal, like processes
+ <braunr> or authentication
+ <braunr> but most importantly, you're not restricted to that, you can add
+ your own interfaces
+ <braunr> on a unix, you'd need new system calls
+ <braunr> or worse, extending through the catch-all ioctl call
+ <giuscri> braunr: mhn ...sorry, not getting that.
+ <braunr> what part ?
+ <kilobug> ioctl has become such a mess :s
+ <giuscri> braunr: when you say that Unix is `file-oriented` you're
+ referring to the fact that sending/receiving data to/from the kernel is
+ designed like sending/receiving data to/from a file ...?
+ <braunr> not merely sending/receiving
+ <braunr> note how formatted your way of thinking is
+ <braunr> you directly think in terms of sending/receiving (i.e. read and
+ write)
+ <giuscri> braunr: (yes)
+ <braunr> that's why unix is file oriented, access to objects is done that
+ way
+ <braunr> on the hurd, the file interface is one interface
+ <braunr> there is nothing preventing you from implementing services with a
+ different interface
+ <braunr> as a real world example, people interested in low latency
+ profesionnal audio usually dislike send/recv
+ <braunr> see
+ for
+ example
+ <kilobug> braunr: how big and messy ioctl has become is a good proof that
+ the Unix way, while powerful, does have its limits
+ <braunr> giuscri: keep in mind the main goal of the hurd is extensibility
+ without special privileges
+ <giuscri> braunr: privileges?
+ <braunr> root
+ <giuscri> braunr: what's wrong with privileges?
+ <braunr> they allow malicious/buggy stuff to happne
+ <braunr> and have dramatic effects
+ <giuscri> braunr: you're obviously *not* referring to the fact that once
+ one have the root privileges could change some critical-data
+ <giuscri> ?
+ <braunr> i'm referring to why privilege separation exists in the first
+ place
+ <braunr> if you have unprivileged users, that's because you don't want them
+ to mess things up
+ <braunr> on unix, extending the system requires privileges, giving those
+ who do it the ability to destroy everything
+ <giuscri> braunr: yes, I think the same
+ <braunr> the hurd is designed to allow unprivileged users to extend their
+ part of the system, and to some extent share that with other users
+ <braunr> although work still remains to completely achieve that
+ <giuscri> braunr: mhn ...that's the `server`-layer between the
+ single-application and kernel ?
+ <braunr> the multi-server based approach not only allows that, but
+ mitigates damage even when privileged servers misbehave
+ <braunr> one aspect of it yes
+ <braunr> but as i was just saying, even root servers can't mess things too
+ much
+ <braunr> for example, our old (sometimes buggy) networking stack can be
+ restarted when it behaves wrong
+ <braunr> the only side effect being some applications (ssh and exim come to
+ mind) which need to be restarted too because they don't expect the
+ network stack to be restarted
+ <giuscri> braunr: ...instead?
+ <braunr> ?
+ <kilobug> giuscri: on Linux, if the network stack crash/freezes, you don't
+ have any other option than rebooting the system - usually with a nice
+ "kernel pani"
+ <kilobug> giuscri: and you may even get filesystem corruption "for free" in
+ the bundle
+ <braunr> and hoping it didn't corrupt something important like file system
+ caches before being flushed
+ <giuscri> kilobug, braunr : mhn, ook
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
index b07df939..ebbad1a4 100644
--- a/open_issues/arm_port.mdwn
+++ b/open_issues/arm_port.mdwn
@@ -273,3 +273,56 @@ architecture.
<slpz> braunr: OK, thanks. I'm interested on it, and didn't want to
duplicate efforts.
<braunr> little addition: it may have started, but we don't know about it
+# IRC, freenode, #hurd, 2013-09-18
+ <Hooligan0> as i understand ; on startup, vm_resident.c functions configure
+ the whole available memory ; but at this point the system does not split
+ space for kernel and space for future apps
+ <Hooligan0> when pages are tagged to be used by userspace ?
+ <braunr> Hooligan0: at page fault time
+ <braunr> the split is completely virtual, vm_resident deals with physical
+ memory only
+ <Hooligan0> braunr: do you think it's possible to change (at least)
+ pmap_steal_memory to mark somes pages as kernel-reserved ?
+ <braunr> why do you want to reserve memory ?
+ <braunr> and which memory ?
+ <Hooligan0> braunr: first because on my mmu i have two entry points ; so i
+ want to set kernel pages into a dedicated space that never change on
+ context switch (for best cache performance)
+ <Hooligan0> braunr: and second, because i want to use larger pages into
+ kernel (1MB) to reduce mmu work
+ <braunr> vm_resident isn't well suited for large pages :(
+ <braunr> i don't see the effect of context switch on kernel pages
+ <Hooligan0> at many times, context switch flush caches
+ <braunr> ah you want something like global pages on x86 ?
+ <Hooligan0> yes, something like
+ <braunr> how is it done on arm ?
+ <Hooligan0> virtual memory is split into two parts depending on msb bits
+ <Hooligan0> for example 3G/1G
+ <Hooligan0> MMU will use two pages tables depending on vaddr (hi-side or
+ low-side)
+ <braunr> hi is kernel, low is user ?
+ <Hooligan0> so, for the moment i've put mach at 0xC0000000 -> 0xFFFFFFFF ;
+ and want to use 0x00000000 -> 0xBFFFFFFF for userspace
+ <Hooligan0> yes
+ <braunr> ok, that's what is done for x86 too
+ <Hooligan0> 1MB pages for kernel ; and 4kB (or 64kB) pages for apps
+ <braunr> i suggest you give up the large page stuff
+ <braunr> well, you can use them for the direct physical mapping, but for
+ kernel objects, it's a waste
+ <braunr> or you can rewrite vm_resident to use something like a buddy
+ allocator but it's additional work
+ <Hooligan0> for the moment it's waste ; but with some littles changes this
+ allow only one level of allocation mapping ; -i think- it's better for
+ performances
+ <braunr> Hooligan0: it is, but not worth it
+ <Hooligan0> will you allow changes into vm_resident if i update i386 too ?
+ <braunr> Hooligan0: sure, as long as these are relevant and don't introduce
+ regressions
+ <Hooligan0> ok
+ <braunr> Hooligan0: i suggest you look at x15, since you may want to use it
+ as a template for your own changes
+ <braunr> as it was done for the slab allocator for example
+ <braunr> e.g. x15 already uses a buddy allocator for physical memory
diff --git a/open_issues/boehm_gc.mdwn b/open_issues/boehm_gc.mdwn
index 7f860bba..623dcb83 100644
--- a/open_issues/boehm_gc.mdwn
+++ b/open_issues/boehm_gc.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -433,3 +434,92 @@ restults of GNU/Linux and GNU/Hurd look very similar.
<civodul> pinotree: is it a Debian-specific change, or included upstream?
<pinotree> libgc using SIGUSR1/2? upstream
<civodul> ok
+### IRC, freenode, #hurd, 2013-09-03
+ <congzhang> braunr: when will libc malloc say memory corruption?
+ <braunr> congzhang: usually on free
+ <braunr> sometimes on alloc
+ <congzhang> and after one thread be created
+ <congzhang> I want to know why and how to find the source
+ <congzhang> does libgc work well on hurd?
+ <braunr> i don't think it does
+ <congzhang> so , why it can't?
+ <braunr> congzhang: what ?
+ <congzhang> libgc was not work on hurd
+ <pinotree> why?
+ <congzhang> I try porting dotgnu
+ <braunr> ah
+ <braunr> nested signal handling
+ <congzhang> one program always receive Abort signal
+ <pinotree> and why it should be a problem in libgc?
+ <congzhang> for malloc memory corruption
+ <braunr> libgc relies on this
+ <congzhang> yes
+ <congzhang> so, is there a workaround to make it work?
+ <braunr> show the error please
+ <congzhang>
+ <pinotree> where's libgc?
+ <congzhang> i compile dotgnu with enable-gc
+ <pinotree> so?
+ <congzhang> I am not sure about it
+ <pinotree> so why did you say earlier that libgc doesn't work?
+ <congzhang> because after I see one thread was created notice by gdb, it
+ memory corruption
+ <pinotree> so what?
+ <congzhang> maybe gabage collection happen, and gc thread start
+ <pinotree> that's speculation
+ <pinotree> you cannot debug things speculating on code you don't know
+ <pinotree> less speculation and more in-deep debugging, please
+ * congzhang I try again, to check weather thread list changing
+ <congzhang> sorry for this
+ <braunr> it simply looks like a real memory corruption (an overflow)
+ <congzhang> maybe PATH related problem
+ <pinotree> PATH?
+ <congzhang> yes
+ <braunr> PATH_MAX
+ <braunr> but unlikely
+ <congzhang> csant do path traverse
+ <congzhang> I fond the macro
+ <congzhang> found
+ <congzhang> #if defined(__sun__) || defined(__BEOS__)
+ <congzhang> #define BROKEN_DIRENT 1
+ <congzhang> #endif
+ <congzhang> and so for hurd?
+ <pinotree> BROKEN_DIRENT doesn't say much about what it does
+ <WhiteKIBA> nope
+ <WhiteKIBA> whoops
+ <congzhang> it seems other port meet the trouble too
+ <pinotree> which trouble?
+ <congzhang>
+ <congzhang> (gdb) ptype struct dirent
+ <congzhang> type = struct dirent {
+ <congzhang> __ino_t d_ino;
+ <congzhang> unsigned short d_reclen;
+ <congzhang> unsigned char d_type;
+ <congzhang> unsigned char d_namlen;
+ <congzhang> char d_name[1];
+ <congzhang> }
+ <congzhang>
+ <congzhang> d_name should be char[PATH_MAX]?
+ <congzhang> and
+ <pinotree> no
+ <braunr> stop pasting that much
+ <_d3f> uhm PATH_MAX on the hurd?
+ <braunr> and stop saying nonsense
+ <congzhang> sorry, i think four line was not worth to pastbin
+ <pinotree> they are 8
+ <congzhang> never again
+ <braunr> just try by defining BROKEN_DIRENT to 1 in all cases and see how
+ it goes
+ * congzhang read dir.c again
+ <congzhang> braunr: it does not crash this time, I do more test
+#### IRC, freenode, #hurd, 2013-09-04
+ <congzhang> hi, I am dotgnu work on hurd, and even winforms app
+ <congzhang> s/am/make
+ <congzhang> and maybe c# hello world translate another day :)
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 98454d45..65ab52df 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -197,4 +197,14 @@ In context of [[select]].
"atomic" update of the struct with time :)
+# IRC, freenode, #hurd, 2013-09-04
+ <teythoon> do we have CLOCK_MONOTONIC ?
+ <braunr> teythoon: i think we do but it's actually a simple offset from
+ <teythoon> ah never mind, I do hate this posix time interface anyways
+ <braunr> really ?
+ <braunr> i think librt is decent
# Candidate for [[vDSO]] code?
diff --git a/open_issues/cloud.mdwn b/open_issues/cloud.mdwn
new file mode 100644
index 00000000..58ed2f5b
--- /dev/null
+++ b/open_issues/cloud.mdwn
@@ -0,0 +1,49 @@
+[[!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
+Some *cloud*y things.
+# [[!wikipedia OpenStack]]
+## IRC, freenode, #hurd, 2013-09-21
+ <jproulx> Hmmm, was hoping to run hurd on my kvm based openstack cloud, but
+ no virtio.
+ <jproulx> I see "Write virtio drivers for KVM. Ideally they would be
+ userland" is listed as a "small hack", as a sysadmin rather than an OS
+ hacker it doesn't sound small to me, but if there's some standard
+ documentation on porting drivers I could take a run at it.
+ <youpi> well, perhaps "small" is not the proper word
+ <youpi> compared to e.g. revamping disk i/o :)
+ <youpi> it's not something one can achieve in e.g. 1h, for instance
+ <youpi> it's not something straightforward either, one has to get
+ documentation about virtio (I don't know what exists), and get
+ documentation about the mach device interface (that's in the gnumach
+ manual, the devnode translator can be used as a skeleton)
+ <youpi> jproulx: openstack imposes the use of virtio drivers? that's odd
+ <jproulx> that's more like I'd expect. I there's enough search terms in
+ your response for me to see what's really involved
+ <jproulx> youpi it doesn't impose that but it is how mine is configured the
+ other thousand VMs are happier that way.
+ <jproulx> I can look at that side too and see if I need to have everything
+ use the same device settings or if I can control it per instance
+ <jproulx> A bit of a non-sequitur at this point but just in case someone
+ searches the transcripts and sees my questions about hurd on openstack,
+ yes it is possible to specify non-virtio devices per image, here's the
+ commandline to load sthibault's qemu image into openstack with devices
+ that work:
+ <jproulx> glance image-create --property hw_disk_bus=ide --property
+ hw_cdrom_bus=ide --property hw_vif_model=rtl8139 --disk-format raw
+ --container-format bare --name gnu-hurd --copy-from
+ <youpi> jproulx: thanks, I've pushed it on the wiki
diff --git a/open_issues/crash_server.mdwn b/open_issues/crash_server.mdwn
index 7ed4afbf..5182df6f 100644
--- a/open_issues/crash_server.mdwn
+++ b/open_issues/crash_server.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -189,6 +189,65 @@ one...
+# IRC, freenode, #hurd, 2013-09-07
+ <rekado> I'm trying to investigate a crash in pfinet, so it will actually
+ die. I just want to know why it dies and what the value of a few
+ variables has been when it died.
+ <teythoon> have you tried to make it dump core?
+ <rekado> oh, good idea.
+ <rekado> I'll try that.
+ <teythoon> do you know how?
+ <rekado> I don't, but I think I can figure it out.
+ <teythoon> look into /servers
+ <rekado> do I just have to set CRASHSERVER=/servers/crash-dump-core and run
+ pfinet in that environment?
+ <teythoon> possibly, I've never heard of CRASHSERVER, but it's certainly
+ plausible ;)
+ <teythoon> I just link crash to crash-dump-core, that way it is permanent
+ and for all processes
+ <rekado> found it in the website contents
+ <rekado> gotta try that.
+ <rekado> hmm, I can't get pfinet to dump core; linked /servers/crash to
+ /servers/crash-dump-core and compiled pfinet to raise(6) at one point.
+ <rekado> But no core file is created.
+ <teythoon> :/
+ <teythoon> rekado: try cd /tmp ; cat & kill -SIGILL %% to see if that dumps
+ core
+ <rekado> yes, this works.
+ <rekado> I replaced the original pfinet with my crashing version.
+ <rekado> Should it dump core to /hurd then?
+ <teythoon> I'm not sure about it's wd
+ <teythoon> hm, ok, I just did settrans -ca foo /hurd/pfinet and then killed
+ that pfient with SIGILL and it dumped core
+ <teythoon> to the directory I issued the settrans from
+ <rekado> So I must run it myself. I can't just replace the original binary
+ and have it dump core somewhere.
+ <teythoon> it seems that you have to use settrans -ca to start an active
+ translator
+ <teythoon> do fsysopts /servers/socket/2 to find out the cmdline of your
+ pfinet
+ <rekado> that's very helpful.
+ <rekado> thanks
+ <teythoon> then use this to restart it, e.g.:
+ <teythoon> settrans -afg /servers/socket/2 $(fsysopts /servers/socket/2)
+ <teythoon> if it dies it should dump core to you cwd
+ <rekado> great. Thank you very much. I had been wondering how to get the
+ full cmdline of pfinet.
+ * rekado makes a note of fsysopts
+ <rekado> yup, there's the core file. Nice.
+ <teythoon> cool 8D
+ <teythoon> btw, in case using gdb doesn't work out for your problem, if you
+ start pfinet (or any translator) this way (with -a == active), you can
+ write stuff to stderr
+ <rekado> yeah, I noticed that. The assert() call wrote to stderr. Useful.
+ <braunr> rekado: core dumps are another not-working-well feature of the
+ hurd :/
+ <braunr> i recommend attaching
+ <tschwinge> rekado: In case that's still helpful:
+ <>.
If someone is working in this area, they may want to have a look at
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
index 2f02579e..a41515a1 100644
--- a/open_issues/dbus.mdwn
+++ b/open_issues/dbus.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -14,15 +15,17 @@ The dbus problems are due to missing scm credentials [[sendmsg_scm_creds]] and s
[[pflocal_socket_credentials_for_local_sockets]]. There was also a problem with short timeout in
[[select]], but that has been solved in Debian by setting a minimum timeout of 1ms.
-IRC, freenode, #hurd, 2011-11-26:
+# IRC, freenode, #hurd, 2011-11-26
<antrik> BTW, how much effort is necessary to fix dbus?
<pinotree> basically, have pflocal know who's the sender
(pid/uid/gid/groups) in the socket send op
-IRC, freenode, #hurd, 2011-12-16:
+# IRC, freenode, #hurd, 2011-12-16
<braunr> pinotree: what's the problem with dbus ?
<pinotree> braunr: select() returning 0 changed fd's with very short (eg <
@@ -53,7 +56,8 @@ IRC, freenode, #hurd, 2011-12-16:
<braunr> hm i agree with neal, i don't understand why the timeout is given
to the kernel as part of the mach_msg call
-IRC, freenode, #hurd, 2011-12-20:
+# IRC, freenode, #hurd, 2011-12-20
<braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
<braunr> only SCM_RIGHTS
@@ -88,3 +92,164 @@ IRC, freenode, #hurd, 2011-12-20:
<pinotree> iirc roland didn't like one or more parts of it (but i could be
<braunr> ok
+# IRC, freenode, #hurd, 2013-07-17
+ <teythoon> btw pinotree, what happened to your efforts to make dbus work?
+ <pinotree> not much, my initial patch was just a crude hack, a better
+ solution requires more thinkering and work
+ <teythoon> yes, ive seen that
+ <teythoon> but that was only a tiny patch against the libc, surely there
+ must be more to that?
+ <pinotree> not really
+ <teythoon> and the proper fix is to patch pflocal to query the auth server
+ and add the credentials?
+ <pinotree> possibly
+ <teythoon> that doesn't sound to bad, did you give it a try?
+ <pinotree> not really, got caught in other stuff
+# IRC, freenode, #hurd, 2013-09-02
+ <gnu_srs1> something is wrong with libc0.3 since the switch to 2.17. dbus
+ does not run any longer when rebuilt
+ <gnu_srs1> the latest build of dbus was with 2.13: libc0.3-dev: already
+ installed (2.13-38)
+ <pinotree> debug it
+ <gnu_srs1> Yes, I will. Maybe somebody could rebuild it and verify my
+ findings?
+ <pinotree> gnu_srs1: your finding is "doesn't work", which is generic and
+ does not help without investigation
+ <gnu_srs1> just rebuild it and: e.g. ./build-debug/bus/dbus-daemon --system
+ (--nofork)
+ <pinotree> gnu_srs1: please, debug it
+ <gnu_srs1> I have partially already. But maybe the problems only shows on
+ my box. I'll rebuild on another box before continuing debugging.
+ <pinotree> gnu_srs1: are you, by chance, running a libc or something else
+ with your scm_creds work?
+ <gnu_srs1> I did, but I've backed to 2.17-92 right now.
+ <gnu_srs1> sane problem with dbus on another box, something's fishy:-(
+ <gnu_srs1> braunr: any good way to find out if the dbus problems are with
+ libpthread? Setting a breakpoint with libc0.3-dbg installed.
+ <braunr> gnu_srs1: i don't know
+See [[glibc]], *Missing interfaces, amongst many more*, *`SOCK_CLOEXEC`*.
+# IRC, freenode, #hurd, 2013-09-04
+ <gnu_srs> Hi, looks like dbus requires abstract socket namespace: #undef
+ <pinotree> uh?
+ <pinotree> abstract unix sockets are a Linux feature, and surely it is not
+ mandatory for dbus
+ <gnu_srs> Looks like dbus exits if they are not supported:
+ <gnu_srs> dbus_set_error (error, DBUS_ERROR_NOT_SUPPORTED, "Operating
+ system does not support abstract socket namespace\n");   _dbus_close
+ (listen_fd, NULL); 1061  return -1;
+ <pinotree> that is enclosed in a if (abstract)
+ <pinotree> and that parameter is set to true in other places (eg
+ dbus/dbus-server-unix.c) only when HAVE_ABSTRACT_SOCKETS is defined
+ <pinotree> so no, abstract sockets are not mandatory
+ <gnu_srs> Well this code is executed e.g. when running emacs remotely in
+ X. Have to dig deeper then to see why.
+ <pinotree> maybe it could have to do the fact that your dbus server is
+ running in linux and runs by default using such sockets type
+ <pinotree> but yes, you need to dig better
+ <gnu_srs> pinotree: You are right. when running natively the problem is:
+ <pinotree> *drums*
+ <gnu_srs> Manually: Process /usr/lib/at-spi2-core/at-spi-bus-launcher
+ exited with status 1
+ <pinotree> eh?
+ <gnu_srs> Error retrieving accessibility bus address:
+ org.freedesktop.DBus.Error.Spawn.ChildExited: ^
+ <pinotree> most probably that service does not start due to the lack of
+ socket credentials which affects dbus
+ <pinotree> uninstall or disable those additional services, they are not
+ your problem
+ <gnu_srs> credentials is enabled. which services to remove?
+ <pinotree> dunno
+# IRC, freenode, #hurd, 2013-09-11
+ <gnu_srs> Hi, looks like frebsd had (2008) the same problem as hurd when
+ sending credentials over PF_INET:
+ <gnu_srs>
+ <gnu_srs> Since the dbus code is about the same now (2013), maybe they
+ added support?
+ <gnu_srs> The next message in the thread confirms that the dbus code is
+ invalid, does anybody have pointers?
+ <pinotree> from what i've seen so far, socket credentials are done only for
+ local sockets (ie PF_UNIX)
+ <pinotree> i don't see how things like uid/gid/pid of the socket endpoint
+ can have anything to do with AF_INET
+ <pinotree> and socket credentials in dbus are used only in the [local]
+ socket transport, so there's no issue
+# IRC, freenode, #hurd, 2013-09-12
+ <gnu_srs> pinotree: Yes, there is an issue with dbus and AF_INET, see
+ test/corrupt.c: tests /corrupt/tcp and /corrupt/byte-order/tcp:-/
+ <pinotree> gnu_srs: what's wrong with those? they are just testing the
+ connection over a tcp socket
+ <pinotree> as said above, socket credentials shouldn't be used in such
+ cases
+ <gnu_srs> They are, see also test/relay.c: /relay and /limit tests:-(
+ <pinotree> how are they?
+ <pinotree> please be more specifc...
+ <gnu_srs> Just run the tests yourself with DBUS_VERBOSE=1
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> DBUS_VERBOSE=1 build-debug/test/test-relay
+ <pinotree> you are claiming there is a problem, so please specify what is
+ the actual issue
+ <gnu_srs> same with test-corrupt
+ <gnu_srs> look at the verbose output: Failed to write credentials: Failed
+ to write credentials byte: Invalid argument
+ <gnu_srs> coming from pfinet since PF_INET is used.
+ <pinotree> check what it does on linux then
+ <pinotree> put an abort() at the start of the read/write socket credential
+ functions in dbus-sysdeps-unix.c and see whether it is triggered also on
+ linux
+ <gnu_srs> SO_PEERCRED is used for linux and LOCAL_CREDS is used for
+ kfreebsd, so we are on our own here:-/
+ <pinotree> and linux' SO_PEERCRED works also on AF_INET sockets? i'd doubt
+ it
+ <gnu_srs>
+ <pinotree> yes, i know the difference, but please read what i asked again
+ <gnu_srs> I'll check to be sure...
+ <braunr> gnu_srs: user credentials are not supposed to be passed through an
+ AF_INET socket
+ <braunr> how hard is that to understand ?
+ <gnu_srs> OK, linux use send since CMSGCREDS is not defined to write
+ credentials. Working on how they are received.
+ <gnu_srs> braunr: I do understand, but the dbus code tries to do that for
+ Hurd:-(
+ <pinotree> then it should do that on linux too
+ <pinotree> (since the local socket credentials code is isolated in own
+ functions, and they are called only for the unix transport)
+ <gnu_srs> Happiness:-D, almost all dbus tests pass!
+ <gnu_srs> 17(17) dbus tests pass:)
+ <braunr> gnu_srs: hopefully your patch does things right
+ <gnu_srs> which patch
+ <braunr> adding credentials through unix socket
+ <braunr> isn't that what you're doing ?
+ <gnu_srs> the mail to MLs is from the stock installed packages.
+ <braunr> ?
+ <gnu_srs> the test reports are with the SCM_CREDS patches, but I stumbled
+ on the SCM_RIGHTS issues reported to MLs
+ <gnu_srs> no patches applied, just test the attached file yourself.
+ <braunr> so what's your work about ?
+ <gnu_srs> I'm working on SCM_CREDS, yes, and created patches for dbus,
+ glib2.0 and libc.
+ <gnu_srs> the mail was about some bug in the call to io_restrict_auth in
+ sendmsg.c: without any of my patches applied (another image)
+ <teythoon> gnu_srs: you have to give us more context, how are we supposed
+ to know how to find this sendmsg.c file?
+ <pinotree> (it's in glibc, but otherwise the remark is valid)
+ <pinotree> s/otherwise/anyway/
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 76b80211..9cb31d1c 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -512,6 +512,18 @@ After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
<antrik> hm... good point
+## IRC, freenode, #hurd, 2013-09-20
+ <braunr> i should take some time to integrate my pcap changes into the
+ libpcap debian package at least
+ <pinotree> braunr: if upstream is active, i'd say to go there directly
+ <braunr> the problem with that approach is that netdde is still not part of
+ our upstream code
+ <pinotree> don't understand the relation
+ <braunr> i don't want to send the pcap guys code for an interface that is
+ still not considered upstream ...
# IRC, freenode, #hurd, 2012-08-14
<braunr> it's amazing how much code just gets reimplemented needlessly ...
@@ -642,3 +654,135 @@ In context of [[libpthread]].
<braunr> there is
<braunr> but relatively to other improvements, it's low
+## IRC, freenode, #hurd, 2013-09-14
+ <rekado> I'm slowly beginning to understand the virtio driver framework
+ after reading Rusty's virtio paper and the Linux sources of a few virtio
+ drivers.
+ <rekado> Has anyone started working on virtio drivers yet?
+ <youpi> rekado: nobody has worked on virtio drivers, as I know of
+ <rekado> youpi: I'm still having a hard time figuring out where virtio
+ would fit in in the hurd.
+ <rekado> I'm afraid I don't understand how drivers in the hurd work at all.
+ Will part of this have to be implemented in Mach?
+ <youpi> rekado: it could be implemented either as a Mach driver, or as a
+ userland driver
+ <youpi> better try the second alternative
+ <youpi> i.e. as a translator
+ <youpi> sitting on e.g. /dev/eth0 or /dev/hd0
+## IRC, freenode, #hurd, 2013-09-18
+ <rekado> To get started with virtio I'd like to write a simple driver for
+ the entropy device which appears as a PCI device when running qemu with
+ -device virtio-rng-pci .
+ <braunr> why entropy ?
+ <rekado> because it's the easiest.
+ <braunr> is it ?
+ <braunr> the driver itself may be, but integrating it within the system
+ probably isn't
+ <rekado> It uses the virtio framework but only really consists of a
+ read-only buffer virtqueue
+ <braunr> you're likely to want something that can be part of an already
+ existing subsystem like networking
+ <rekado> All the driver has to do is push empty buffers onto the queue and
+ pass the data it receives back from the host device to the client
+ <rekado> The thing about existing subsystems is: I don't really understand
+ them enough.
+ <rekado> I understand virtio, though.
+ <braunr> but isn't your goal understanding at least one ?
+ <rekado> yes.
+ <braunr> then i suggest working on virtio-net
+ <braunr> and making it work in netdde
+ <rekado> But to write a virtio driver for network I must first understand
+ how to actually talk to the host virtio driver/device.
+ <braunr> rekado: why ?
+ <rekado> There is still a knowledge gap between what I know about virtio
+ and what I have learned about the Hurd/Mach.
+ <braunr> are you trying to learn about virtio or the hurd ?
+ <rekado> both, because I'd like to write virtio drivers for the hurd.
+ <braunr> hm no
+ <rekado> with virtio drivers pass buffers to queues and then notify the
+ host.
+ <braunr> you may want it, but it's not what's best for the project
+ <rekado> oh.
+ <braunr> what's best is reusing existing drivers
+ <braunr> we're much too far from having enough manpower to maintain our own
+ <rekado> you mean porting the linux virtio drivers?
+ <braunr> there already is a virtio-net driver in linux 2.6
+ <braunr> so yes, reuse it
+ <braunr> the only thing which might be worth it is a gnumach in-kernel
+ driver for virtio block devices
+ <braunr> because currently, we need our boot devices to be supported by the
+ kernel itself ...
+ <rekado> when I boot the hurd with qemu and the entropy device I see it as
+ an unknown PCI device in the output of lspci.
+ <braunr> that's just the lspci database which doesn't know it
+ <rekado> Well, does this mean that I could actually talk to the device
+ already? E.g., through libpciaccess?
+ <rekado> I'm asking because I don't understand how exactly devices "appear"
+ on the Hurd.
+ <braunr> it's one of the most difficult topic currently
+ <braunr> you probably can talk to the device, yes
+ <braunr> but there are issues with pci arbitration
+ * rekado takes notes: "pci arbitration"
+ <rekado> so, this is about coordinating bus access, right?
+ <braunr> yes
+ <braunr> i'm not a pci expert so i can't tell you much more
+ <rekado> heh, okay.
+ <rekado> what kind of "issues with pci arbitration" are you referring to,
+ though?
+ <rekado> Is this due to something that Mach isn't doing?
+ <braunr> ideally, mach doesn't know about pci
+ <braunr> the fact we still need in-kernel drivers for pci devices is a big
+ problem
+ <braunr> we may need something like a pci server in userspace
+ <braunr> on l4 system it's called an io server
+ <rekado> How do in-kernel drivers avoid these issues?
+ <braunr> they don't
+ <rekado> Or rather: why is it they don't have these issues?
+ <braunr> they do
+ <rekado> oh.
+ <braunr> we had it when youpi added the sata driver
+ <braunr> so currently, all drivers need to avoid sharing common interrupts
+ for example
+ <braunr> again, since i'm not an expert about pci, i don't know more about
+ the details
+ <Hooligan0> pci arbitrations are made by hardware ... no ?
+ <braunr> Hooligan0: i don't know
+ <braunr> i'm not merely talking about bus mastering here
+ <braunr> simply preventing drivers from mapping the same physical memory
+ should be enforced somewhere
+ <braunr> i'm not sure it is
+ <braunr> same for irq sharing
+ <Hooligan0> braunr : is the support for boot devices into the kernel is
+ really needed if a loader put servers into the memory before starting
+ mach ?
+ <braunr> Hooligan0: there is a chicken-and-egg problem during boot,
+ whatever the solution
+ <braunr> obviously, we can preload from memory, but then you really want
+ your root file system to use a disk
+ <braunr> Hooligan0: the problem with preloading from memory is that you
+ want the root file system to use a real device
+ <braunr> the same way / refers to one on unix
+ <braunr> so you have an actual, persistent hierarchy from which the system
+ can be initialized and translators started
+ <braunr> you also want to share as much as possible between the early
+ programs and the others
+ <braunr> so for example, both the disk driver and the root file system
+ should be able to use the same libc instance
+ <braunr> this requires a "switch root" mechanism that needs to be well
+ defined and robust
+ <braunr> otherwise we'd just build our drivers and root fs statically
+ <braunr> (which is currently done with rootfs actually)
+ <braunr> and this isn't something we're comfortable with
+ <braunr> so for now, in-kernel drivers
+ <Hooligan0> humm ... disk driver and libc ... i see
+ <Hooligan0> in other way ... disk drivers can use only a little number of
+ lib* functions ; so with a static version, a bit of memory is lots
+ <Hooligan0> s/lots/lost
+ <Hooligan0> and maybe the driver can be hot-replaced after boot (ok ok,
+ it's more simple to say than to write)
diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn
index 5bda0213..085a737a 100644
--- a/open_issues/device_drivers_and_io_systems.mdwn
+++ b/open_issues/device_drivers_and_io_systems.mdwn
@@ -92,3 +92,9 @@ Also see [[user-space device drivers]].
* OSF Mach
* Darwin
+ * IRC, freenode, #hurd, 2013-08-26
+ < stargater> in haiku is a layer wraper for bsd driver
+ < stargater>
diff --git a/open_issues/exec.mdwn b/open_issues/exec.mdwn
index ff3fccf5..fe70123d 100644
--- a/open_issues/exec.mdwn
+++ b/open_issues/exec.mdwn
@@ -10,7 +10,10 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_hurd]]
-IRC, unknown channel, unknown date.
+# IRC, unknown channel, unknown date.
<youpi> oh my, disabling gzip/bzip2 support makes apt preconfigure hang
<youpi> support in exec* I meant
@@ -18,6 +21,50 @@ IRC, unknown channel, unknown date.
<youpi> now a funny bug: if I disable gzip/bzip2 support from exec
<youpi> trying to run a zero-byte file hangs
+## IRC, freenode, #hurd, 2013-08-01
+ <teythoon> uh, all the non trivial exec server code has #ifdef'd BFD code
+ all over it and it looks like that isn't even used anymore
+ <teythoon> that's too bad actually, I figured out how to get the values
+ from BFD, not so for the other elf parser that is used instead
+## IRC, freenode, #hurd, 2013-08-05
+ <teythoon> btw, there is a Debian bug concerning zipped executables. now
+ I'm not sure if I understood the problem, but gziped and bzip2ed
+ executables work for me
+ <teythoon> (not that I'm a big fan of that particular feature)
+ <youpi> iirc these somehow got fixed yes
+ <youpi> something like a previous out of bound access
+ <teythoon> the exec server contains lot's of code that is unused and
+ probably bit rot (#ifdef BFD) or otherwise ignored (#if 0)
+ <youpi> yes :/
+ <teythoon> and there's gunzipping and bunzip2ing, which we probably don't
+ want anyway
+ <pinotree> why not?
+ <teythoon> we should strip all that from exec and start adding features
+ <teythoon> pinotree: b/c it's slow and the gain is questionable
+ <teythoon> it breaks mmapping the code in
+ <teythoon> exec/exec.c is huge (~2300 lines) and complex and it is an
+ essential server
+ <teythoon> and I wonder if the unzipping is done securely, e. g. if it's
+ not possible to crash exec with an maliciously compressed executable
+## IRC, freenode, #hurd, 2013-09-12
+ <rekado> The zip code in hurd/exec/ looks really complicated; does it
+ really just unpack zipped files in memory (which could be replaced by
+ library calls) or is there something else going on?
+ <braunr> rekado:
+ <rekado> braunr: interesting. Thanks.
+ <rekado> Does this mean that the "small hack entry" on the contributing
+ page to use libz and libbz2 in exec is no longer valid?
+ <braunr> probably
May want to have a look at using BFD / libiberty/simpleobject.
diff --git a/open_issues/exec_leak.mdwn b/open_issues/exec_leak.mdwn
deleted file mode 100644
index b58d2c81..00000000
--- a/open_issues/exec_leak.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-[[!meta copyright="Copyright © 2012 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
-[[!tag open_issue_hurd]]
-# IRC, freenode, #hurd, 2012-08-11
- <braunr> the exec servers seems to leak a lot
- <braunr> server*
- <braunr> exec now uses 109M on darnassus
- <braunr> it really leaks a lot
- <pinotree> only 109mb? few months ago, exec on exodar was taking more than
- 200mb after few days of uptime with builds done
- <braunr> i wonder how much it takes on the buildds
-# IRC, freenode, #hurd, 2012-08-17
- <braunr> the exec leak is tricky
- <braunr> bddebian: btw, look at the TODO file in the hurd source code
- <braunr> bddebian: there is a not from thomas bushnell about that
- <braunr> "*** Handle dead name notifications on execserver ports. !
- <braunr> not sure it's still a todo item, but it might be worth checking
- <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0);
- This is what would need to change right? It should call some cleanup
- routine in the first argument?
- <bddebian> Would be ideal if it could just use deadboot() from exec.
- <braunr> bddebian: possible
- <braunr> bddebian: hum execboot, i'm not so sure
- <bddebian> Execboot is the exec task, no?
- <braunr> i don't know what execboot is
- <bddebian> It's from libdiskfs
- <braunr> but "diskfs_execboot_class" looks like a class of ports used at
- startup only
- <braunr> ah
- <braunr> then it's something run in the diskfs users ?
- <bddebian> yes
- <braunr> the leak is in exec
- <braunr> if clients misbehave, it shouldn't affect that server
- <bddebian> That's a different issue, this was about the TODO thing
- <braunr> ah
- <braunr> i don't know
- <bddebian> Me either :)
- <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled
- at my results..
- <braunr> ?
- <bddebian> Where my counters are zero if I always increment on different
- vars but wild freaking numbers if I increment on malloc and decrement on
- free
diff --git a/open_issues/exec_memory_leaks.mdwn b/open_issues/exec_memory_leaks.mdwn
index d504c4f0..67281bdc 100644
--- a/open_issues/exec_memory_leaks.mdwn
+++ b/open_issues/exec_memory_leaks.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -12,8 +12,56 @@ License|/fdl]]."]]"""]]
There are is some memory leak in [[`exec`|hurd/translator/exec]].
-# I
+# IRC, freenode, #hurd, 2012-08-11
+ <braunr> the exec servers seems to leak a lot
+ <braunr> server*
+ <braunr> exec now uses 109M on darnassus
+ <braunr> it really leaks a lot
+ <pinotree> only 109mb? few months ago, exec on exodar was taking more than
+ 200mb after few days of uptime with builds done
+ <braunr> i wonder how much it takes on the buildds
+## IRC, freenode, #hurd, 2012-08-17
+ <braunr> the exec leak is tricky
+ <braunr> bddebian: btw, look at the TODO file in the hurd source code
+ <braunr> bddebian: there is a not from thomas bushnell about that
+ <braunr> "*** Handle dead name notifications on execserver ports. !
+ <braunr> not sure it's still a todo item, but it might be worth checking
+ <bddebian> braunr: diskfs_execboot_class = ports_create_class (0, 0);
+ This is what would need to change right? It should call some cleanup
+ routine in the first argument?
+ <bddebian> Would be ideal if it could just use deadboot() from exec.
+ <braunr> bddebian: possible
+ <braunr> bddebian: hum execboot, i'm not so sure
+ <bddebian> Execboot is the exec task, no?
+ <braunr> i don't know what execboot is
+ <bddebian> It's from libdiskfs
+ <braunr> but "diskfs_execboot_class" looks like a class of ports used at
+ startup only
+ <braunr> ah
+ <braunr> then it's something run in the diskfs users ?
+ <bddebian> yes
+ <braunr> the leak is in exec
+ <braunr> if clients misbehave, it shouldn't affect that server
+ <bddebian> That's a different issue, this was about the TODO thing
+ <braunr> ah
+ <braunr> i don't know
+ <bddebian> Me either :)
+ <bddebian> For the leak I'm still focusing on do-bunzip2 but I am baffled
+ at my results..
+ <braunr> ?
+ <bddebian> Where my counters are zero if I always increment on different
+ vars but wild freaking numbers if I increment on malloc and decrement on
+ free
+# 2012-11-25
After twelve hours worth of `fork/exec` ([[GCC]]'s `check-c` part of the
testsuite), we got:
@@ -29,7 +77,7 @@ quite noticeable. In comparison:
276 0 3 1 1 344 442M 28.2M 0.6 48:09.36 91min /hurd/ext2fs /dev/hd2s5
-# II
+# 2012-12-20
After running the libtool testsuite for some time:
diff --git a/open_issues/fakeroot_eagain.mdwn b/open_issues/fakeroot_eagain.mdwn
index 6b684a04..168ddf7d 100644
--- a/open_issues/fakeroot_eagain.mdwn
+++ b/open_issues/fakeroot_eagain.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -132,7 +132,7 @@ License|/fdl]]."]]"""]]
<braunr> or rather, a lot more
<braunr> (or maybe not, since it leaks only in some cases)
<braunr> pinotree: actually, the behaviour under linux is the same with the
alternative correctly set, whereas faked-tcp is restarted (if used at
diff --git a/open_issues/gccgo.mdwn b/open_issues/gccgo.mdwn
index 9e724b95..a3c0e1d1 100644
--- a/open_issues/gccgo.mdwn
+++ b/open_issues/gccgo.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -38,6 +38,15 @@ been working on this, has some (unpublished) patches, and this was blocked on
+### IRC, freenode, #hurd, 2013-08-26
+ < gnu_srs> tschwinge: on
+ you might change
+ the text, my patches are published
+ < gnu_srs>
+ to msg00052.html
## `getcontext`/`makecontext`/`setcontext`/`swapcontext` usage analysis
In context of [[glibc/t/tls-threadvar]]. Looking at GCC trunk commit
diff --git a/open_issues/gdb.mdwn b/open_issues/gdb.mdwn
index 67a38e96..aec797ee 100644
--- a/open_issues/gdb.mdwn
+++ b/open_issues/gdb.mdwn
@@ -355,6 +355,18 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
Cannot access memory at address 0x6c62616e
(gdb) testcase ../../../Ferry_Tagscherer/gdb/testsuite/gdb.base/attach-pie-noexec.exp completed in 3 seconds
+ IRC, freenode, #hurd, 2013-09-06:
+ <gnu_srs1> How to debug a program that works in the shell but Cannot
+ access memory at address ... in gdb?
+ <tschwinge> Build it without -pie -- but that is just a guess of what
+ might be going on.
+ * tschwinge clearly has spent enough time with obscure things to be
+ able to make such guesses.
+ <gnu_srs1> tschwinge: looks like -fPIE is used.
+ <gnu_srs1> verified: some (all?) executables compiled with -fPIE, -fpie
+ and linked with -pie cannot be debugged in gdb :(
* `solib-event stop`
Running ../../../Ferry_Tagscherer/gdb/testsuite/gdb.mi/mi-catch-load.exp ...
@@ -540,3 +552,34 @@ like `gdb/testsuite/boards/cc-with-tweaks.exp` would help, or setting
+# Open Issues
+## [[tag/open_issue_gdb]]
+## `info files` SIGSEGV
+[[!tag open_issue_gdb]]
+### IRC, freenode, #hurd, 2013-09-07
+ <rekado> I'm trying to debug pfinet, but I'm not very familiar with gdb.
+ Tried to attach to the running pfinet process (built with debug symbols),
+ set a breakpoint and ... when I ran "info files" the process segfaulted.
+ <teythoon> which process segfaults, pfinet or gdb?
+ <rekado> gdb segfaults.
+## Watchpoints
+[[!tag open_issue_gdb]]
+### IRC, freenode, #hurd, 2013-09-16
+ <gnu_srs> tschwinge: Is gdb watch known to fail on hurd? It hangs for me
+ when logged in via ssh.
+ <tschwinge> gnu_srs: Don't know about GDB's watch command. Are you sure it
+ is hanging?
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index 31437744..b453b44f 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -281,14 +281,55 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8
+ IRC, OFTC, #debian-hurd, 2013-09-09:
+ <gg0> does hurd MADV_DONTNEED or MADV_FREE or none?
+ <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED
+ but i don't know what i'm talking about, so it could build with
+ IRC, OFTC, #debian-hurd, 2013-09-10:
+ <youpi> gg0: it implements none, even if it defines DONTNEED (but
+ not FREE)
+ See also:
+ gnash (0.8.11~git20130903-1) unstable; urgency=low
+ * Git snapshot.
+ + Embedded jemalloc copy has been replaced by system one.
+ [...]
+ - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream.
* `msync`
- * `sys/epoll.h`
+ * `epoll`, `sys/epoll.h`
Used by [[wayland]], for example.
+ IRC, freenode, #hurd, 2013-08-08:
+ <nalaginrut> is there any possible to have kquque/epoll alike
+ things in hurd? or there is one?
+ <braunr> nalaginrut: use select/poll
+ <nalaginrut> is it possible to implement epoll?
+ <braunr> it is
+ <braunr> we don't care enough about it to do it
+ <braunr> (for now)
+ <nalaginrut> well, since I wrote a server with Guile, and it could
+ take advantage of epoll, never mind, if there's no, it'll use
+ select automatically
+ <nalaginrut> but if someday someone care about it, I'll be
+ interested on it
+ <braunr> epoll is a scalability improvement over poll
+ <braunr> the hurd being full of scalability issues, this one is
+ clearly not a priority
+ <nalaginrut> ok
* `sys/eventfd.h`
* `sys/inotify.h`
@@ -390,6 +431,429 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8
libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim,
and more.
+ IRC, OFTC, #debian-hurd, 2013-09-08:
+ <pinotree> oh, and even ruby2.0 suffers because of fixed-stack
+ threads
+ <youpi> yes, we definitely need to finish fixing it
+ <youpi> my current work is in our glibc repo, youpi/tls-threadvar
+ <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000
+ is not usable with threadvars
+ <pinotree> all 8 failing tests with that
+ <youpi> maybe we can hand-disable the use of contexts in ruby for
+ now?
+ <pinotree> gg0: ↑ :)
+ <gg0> after the pseudo-patch i RFCed, i don't deserve to say
+ anything else about that :)
+ <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as
+ above :)
+ <gg0> eh maybe i'd just be able to hand-disable failing
+ thread-related _tests_ :)
+ <gg0> i'm still hoping some real developer picks and actually fixes
+ it, seems it's not enough interesting though
+ <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it
+ <gg0> afaiu youpi is working on threadvars-tls migration, which
+ would mean fixing them all. i just meant fixing ruby, which would
+ mean having puppet btw
+ <youpi> gg0: "actually fixing" means fixing threadvars-tls
+ migration
+ <youpi> "just fixing" ruby can be done by simply disabling context
+ use in ruby
+ IRC, OFTC, #debian-hurd, 2013-09-10:
+ <gg0> this one fixes make test by disabling context and giving more
+ time to timing related tests
+ <gg0> make test-all is another story
+ <youpi> gg0: AIUI, the sleep part should get fixed by the next
+ glibc upload, which will include the getclk patch
+ <youpi> but the disabling context part could be good to submit to
+ the debian ruby package, mentioning that this is a workaround for
+ now
+ <gg0> unfortunately still not enough, test-all still fails
+ <youpi> does it make the package not build?
+ <gg0> test-all is the second part of what we call tests
+ <gg0> they build and package (they produce all ruby packages),
+ after that they run debian/run-test-suites.bash which is make
+ test + make test-all
+ <gg0> well after or during the build doesn't matter, it's their
+ testsuite
+ <gg0> ok just failed:
+ <gg0> TestBug4409#test_bug4409 = Illegal instruction
+ <gg0> make: *** [yes-test-all] Error 132
+ <gg0> what to do with Illegal instruction?
+ <gg0> just found 2 words that make everybody shut up :p
+ <pinotree> same as above: debug it
+ <teythoon> gg0: have you confirmed that this is reproducible? I've
+ once had a process die with SIGILL and it was not and I figured
+ it might have been a (qemu?) glitch
+ <gg0> seems i'm running tests which are disabled on _all_ archs,
+ better so
+ <gg0> well, this should be reproducible. i just got it on a qemu, i
+ could try to reproduce it on real hardware but as just said, i
+ was testing tests disabled by maintainer so completely useless
+ <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm
+ as well, I meant did you get this twice in a row?
+ <gg0> to be honest i got another illegal instruction months ago but
+ don't recall doing what
+ <gg0> nope not twice, i've commented it out. then run the remaining
+ and then found out i should not have done what i was doing
+ <gg0> but i could try to reproduce it
+ <gg0> ok now i recall i got it another one few hours ago on real
+ hardware, from logs:
+ <gg0> TestIO#test_copy_stream_socket = Illegal instruction
+ <gg0> teythoon: on real hardware though
+ <gg0> and this is the one i should debug once it finishes, still
+ running
+ IRC, freenode, #hurd, 2013-09-11:
+ <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind:
+ Assertion `! __spin_lock_locked (&ss->critical_section_lock)'
+ failed.
+ <gg0_> and
+ <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51:
+ __pthread_thread_halt: Unexpected error: (ipc/send) invalid
+ destination port.
+ <tschwinge> gg0_: Which libpthread source are these? Stock Debian
+ package?
+ <gg0_> tschwinge: everything debian, ruby rebuilt with
+ which should disable
+ *context
+ IRC, OFTC, #debian-hurd, 2013-09-11:
+ <gg0_> wrt ruby, i'd propose a patch that disables *context and
+ comments out failed tests (a dozen). most of them are timing
+ related, don't always fail
+ <gg0_> if they failed gracefully, we could leave them enabled and
+ just ignoring testsuite result, but most of them block testsuite
+ run when fail
+ <gg0_> anyone against? any better idea (and intention to implement
+ it? :p)?
+ <gg0_> youpi: is disabling some tests acceptable? ^
+ <youpi> it'd be good to at least know what is failing
+ <youpi> so as to know what impact hiding these failures will have
+ <youpi> remember that hiding bugs usually means getting bitten by
+ them even harder later :)
+ <gg0_> many of them use pipes
+ <gg0_> here the final list, see commented out ones
+ <gg0_> and as said some don't always fails
+ <gg0_> test_copy_stream_socket uses a socket
+ <youpi> note that we can still at least build packages with notest
+ <youpi> at least to get the binaries uploaded
+ <youpi> disabling *context should however really be done
+ <youpi> and the pipe issues are concerning
+ <youpi> I don't remember other pipe issues
+ <youpi> so maybe it's a but in the ruby bindings
+ <gg0_> i just remember they didn't die, then something unknown
+ fixed it
+ <youpi> I see something frightening in io.c
+ <youpi> #if BSD_STDIO
+ <youpi> preserving_errno(fseeko(f, lseek(fileno(f),
+ (off_t)0, SEEK_CUR), SEEK_SET));
+ <youpi> #endif
+ <youpi> this looks very much like a workaround for an odd thing in
+ <youpi> it happens that that gets enabled on hurd too, since
+ __MACH__ is defined
+ <youpi> you could try to drop these three lines, just to see
+ <youpi> this is very probably very worth investigating, at any rate
+ <youpi> even just test_gets_limit_extra_arg is a very simple test,
+ that I fail to see why it should ever fail on hurd-i386
+ <youpi> starting debugging it would be a matter of putting printfs
+ in io.c, to check what gets called, with what parameters, etc.
+ <youpi> just a matter of taking the time to do it, it's not very
+ complex
+ <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here
+ <youpi> yes, 1.8
+ <gg0_>
+ <gg0_> landed to sid few days ago
+ <youpi> ah, I have 1.87
+ <youpi> +.
+ <gg0_> my favourites are TestIO#test_copy_stream_socket and
+ TestIO#test_cross_thread_close_fd -> Illegal instruction
+ <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal
+ instruction, sometimes ruby1.9.1:
+ ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion
+ `! __spin_lock_locked (&ss->critical_section_lock)' failed.
+ [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]?
+ <gg0_> trying to debug illegal instruction
+ <gg0_> (yes, i'm not even good at gdbing)
+ <gg0_> any hint?
+ <gg0_> oh found out there's an intree .gdbinit, that might
+ complicate things
+ IRC, OFTC, #debian-hurd, 2013-09-13:
+ <gg0_> where should it be implemented MAP_STACK? plus, is it worth
+ doing it considering migration to tls, wouldn't it be useless?
+ <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions
+ frequency from daily to weekly basis
+ IRC, OFTC, #debian-hurd, 2013-09-14:
+ <gg0_> say i managed to mmap 0x200000-aligned memory
+ <gg0_> now i get almost the same failed tests i get disabling
+ *context
+ <gg0_> that would mean they don't depend on threading
+ IRC, freenode, #hurd, 2013-09-16:
+ <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53:
+ _longjmp_unwind: Assertion `! __spin_lock_locked
+ (&ss->critical_section_lock)' failed.
+ <gg0> by running ruby testsuite, especially during test_read* tests
+ <gg0> read/write operations with pipes
+ <braunr> gg0: that's weird
+ <braunr> gg0: debian glibc ?
+ <gg0> braunr: yep, debian 2.17-92
+ <gg0> sometimes assertion above, sometimes tests in question get
+ stuck reading
+ <gg0> it would be nice reproducing it w/o ruby
+ <gg0> probably massive io on pipes could do the job
+ <gg0> also more nice finding someone who finds it interesting to
+ fix :p
+ <gg0> ruby is rebuilt with, no
+ *context
+ <gg0> pipe function in tests above creates one thread for write,
+ one for read
+ <tschwinge> gg0: About the jmp-unwind assertion failure: is it be
+ chance this issue:
+ <>?
+ I didn't look in detail.
+ <braunr> tschwinge: that's what i thought too about the assertion,
+ which is why i find it strange
+ <gg0> asserting it's not locked then locking it doesn't exclude
+ race conditions
+ IRC, OFTC, #debian-hurd, 2013-09-17:
+ <gg0> youpi: i guess no one saw it anymore since
+ tg-thread-cancel.diff patch
+ <gg0> it =
+ <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though
+ <gg0> another assertion to remove?
+ <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we
+ hold no lock at all at the assertion point
+ <youpi> in jmp-unwind.c, we do hold a lock
+ <youpi> and the assertion might be actually true because all other
+ threads are supposed to hold the first lock before taking the
+ other one
+ <youpi> you could check for that in other places
+ <youpi> and maybe it's the other place which wouldhave to be fixed
+ <youpi> also look for documentation which would say that
+ IRC, freenode, #hurd, 2013-09-17:
+ <braunr_> gg0: is that what we do ??
+ <gg0> braunr: well, i was looking at
+ <gg0> which afaics fixes
+ <gg0> the one i get now is
+ <gg0> 09:12 < youpi> gg0: it's not exactly the same: in
+ hurd_thread_cancel we hold no lock at all at the assertion point
+ <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock
+ <gg0> 09:13 < youpi> and the assertion might be actually true
+ because all other threads are supposed to hold the first lock
+ before taking the other one
+ <braunr> gg0: that assertion is normal
+ <braunr> it says there is a deadlock
+ <braunr> ss->critical_section_lock must be taken before ss->lock
+ <gg0> you mean ss->lock before ss->critical_section_lock
+ <braunr> no
+ <gg0> ah ok got it
+ <braunr> that's a bug
+ <braunr> longjmp
+ <braunr> ugh
+ <braunr> you could make a pass through the various uses of those
+ locks and check what the intended locking protocol should be
+ <braunr> i inferred ss->critical_section_lock before ss->lock from
+ hurd_thread_cancel
+ <braunr> this might be wrong too but considering this function is
+ used a lot, i doubt it
+ <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where
+ lock is before critical_section_lock)
+ <gg0> could we get useful info from gdb'ing the assertion?
+ <tschwinge> gg0: Only if you first get an understanding why it is
+ happening, what you expect to happen instead/why it shall not
+ happen/etc. Then you can perhaps use GDB to verify that.
+ <gg0> i can offer an irc interface if anyone is interested, it's
+ ready, just to attach :)
+ <gg0> this is the test
+ <gg0> pipe function creates two threads
+ <gg0> Attaching to pid 15552
+ <gg0> [New Thread 15552.1]
+ <gg0> [New Thread 15552.2]
+ <gg0> (gdb)
+ IRC, freenode, #hurd, 2013-09-21:
+ <youpi> gg0: it seems the assert (! __spin_lock_locked
+ (&ss->critical_section_lock)); is bogus
+ <youpi> but it'd be good to catch a call trace
+ <youpi> well, it may not be bogus, in case that lock is only ever
+ taken by the thread itself
+ <youpi> in that case, inside longjmp_unwind we're not supposed to
+ have it already
+ <youpi> ok, that's what we had tried to discuss with Roland
+ <youpi> it can happen when playing with thread cancelation
+ <braunr> youpi: the assertion isn't exactly bogus
+ <braunr> the lock ordering is
+ <youpi> braunr: which one are you talking about?
+ <youpi> the one in hurd_thread_cancel looks really wrong
+ <youpi> and some parts of the code keep the critical section lock
+ without ss->lock held, so I don't see how lock ordering can help
+ IRC, OFTC, #debian-hurd, 2013-09-22:
+ <gg0> how much does this patch suck on a scale from 1 to 10?
+ <youpi> well, the stack allocation issue will go away once I get
+ the threadvars away
+ <youpi> I'm working on it right now
+ <youpi> about the lib paths, it makes sense to add the gnu case,
+ but i386-gnu shouldn't be put in the path
+ <gg0> that's great
+ <gg0> so seems the wrong moment for what i've already done
+ ie. asking terceiro what he thinks about patch above :/
+ <gg0> any distro-independent way to get and path?
+ <gg0> ruby as last resource takes them from "ldd ruby"
+ <pinotree> gg0: should work fine then
+ <gg0> well it does. but gnu doesn't have a case so it hits default
+ which is broken
+ <gg0> btw even linux and kfreebsd with debian multipath have broken
+ cases but they don't hit default and get fixed by ldd later
+ <pinotree> why it is broken? are arguments passed to that script?
+ <gg0> i'm not sure about what propose. a broken case so it doesn't
+ hit default like linux and kfbsd
+ <gg0> yes they are :/
+ <pinotree> and which ones are? who executes that script and which
+ arguments does it pass to it?
+ <gg0> other ruby scripts which have nothing to do with libc/libm
+ <pinotree> well, if they pass arguments which should be the paths
+ to libc and libm, they must be getting such paths, aren't they?
+ <gg0> they don't. arguments are other ruby scripts, don't know why,
+ maybe something else broken before
+ <gg0> but that would mean that before there's a smarter path
+ detection way, i doubt
+ <pinotree> then add the case for hurd, but setting both libc and
+ libm as nil
+ <pinotree> so they will be fetched again
+ <gg0> yep and would really ugly
+ <gg0> +be
+ <gg0> "please commit this one which wrongly sets paths."
+ <gg0> an alternative would be removing default case
+ <gg0> or pointing it out by proposing ldd in hurd case might make
+ them review the whole detection
+ <gg0> by setting correct paths like in patch above it wouldn't
+ break a possible hurd-amd64, it would work due to ldd
+ <youpi> gg0: that's why I said the patch is fine, but without the
+ i386-gnu part of the path
+ <youpi> just like it happens to be on linux & kfreebsd
+ <gg0> i might take ldconfig -p output
+ <gg0> to make it uselessly correct from start
+ <gg0>
+ <pinotree> note thar ruby 1.8 is EOL
+ <pinotree> *that
+ <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby
+ 1.8: ruby-trunk, and write like "this bug can be reproduced in
+ Ruby 1.8 as well." --
+ <gg0> i suspect this one won't be the only one i'll file. unless
+ upcoming youpi's tls and braunr's thread destruction patches fix
+ all ruby tests
+ <pinotree> did you check ruby2.0 too, btw?
+ <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of
+ testsuite is not enabled, probably terceiro will enable it soon
+ <gg0> by applying my patch above we'd completely fix current
+ ruby2.0 build (yes because tests are not completely enabled)
+ <pinotree> what you run those extra tests?
+ <gg0>
+ <gg0> make test + make test-all
+ <gg0> (test-all is 2nd part)
+ <gg0> many are problematic. i didn't finish yet to suppress them
+ one-by-one. one i suppress, another one pops up
+ <gg0> either get stuck or well known assertion
+ <pinotree> check those that get stuck :)
+ <gg0> which kind of check?
+ <pinotree> "check" as in "debug"
+ <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to
+ be working, at least at trasferring files from master
+ <gg0> don't know about any advanced usage
+ <pinotree> ruby 1.8 is going to die soon, so testing things against
+ it is not totally useful
+ <gg0> so you assume 1.8 is less broken than 1.9/2.0, right?
+ <pinotree> no
+ <gg0> i just can see it's been built without tests itself too
+ <pinotree> erm no
+ <gg0> well ok, if i can be wrong, i'll be wrong
+ <gg0> i say that after a quick check time ago, might be wrong
+ <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last
+ build log
+ <gg0> ah from pkg-kde-tools
+ <gg0> i hate kde :)
+ <pinotree> no?
+ <gg0> no what?
+ <pinotree> devscripts: /usr/bin/getbuildlog
+ <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs
+ <pinotree> which is not what i said
+ <gg0> wait that's what apt-file found
+ <gg0> maybe i should update it
+ <gg0> is it so recent?
+ <pinotree> no
+ <pinotree> i just added an 's' more at the end of the command, but
+ typing getbu<tab> could have been helpful anyway...
+ <gg0> yeah just got it
+ <gg0> my fault not to have tried to run it before looking for it
+ <pinotree> and btw, i don't see what hating kde has to do with
+ tools developed by qt/kde debian packagers
+ <gg0> j/k i simply don't use kde, never used and apt-file search
+ told me it was from pkg-kde-tools
+ <gg0> btw build log says "make test" fails, doesn't even start. and
+ its failure doesn't block the build
+ <pinotree> exactly
+ <gg0> s/make test/make test-all/
+ <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's
+ missing in packaging
+ IRC, freenode, #hurd, 2013-09-22:
+ <braunr> youpi: i mean the lock order where the assertion occurs is
+ reserved compared to the one in hurd_thread_cancel
+ <braunr> (and the one in hurd_thread_cancel is the same used in
+ hurd condition-related functions)
+ <youpi> "reserved" ?
+ <braunr> reversed
+ <braunr> :)
+ <youpi> by "the assertion occurs", you mean gg0's spot?
+ <braunr> yes
+ <youpi> well , the assertion also happens in hurd_thread_cancel
+ <braunr> it does oO
+ <braunr> i didn't see that
+ <youpi> but otherwise yes, it's completely bogus that we have both
+ locking in different orders
+ <youpi> could you submit the fix for jmp-unwind.c to upstream?
+ <braunr> what fix ?
+ <youpi> reversing the lock order
+ <braunr> ah, simply that
+ <youpi> (well, provided that hurd_thread_cancel is right)
+ <braunr> that's what i suggested to gg0
+ <braunr> to check where those locks are held and determine the
+ right order
* `recvmmsg`/`sendmmsg` (`t/sendmmsg`)
From [[!message-id ""]],
@@ -401,13 +865,140 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8
Then perhaps the Linux fallback case should be that instead of stubs,
+ IRC, freenode, #hurd, 2013-09-02:
+ <gnu_srs1> Do we support accept4 with the SOCK_CLOEXEC flag?
+ <gnu_srs1> According to the code in sysdeps/mach/hurd/accept4.c
+ that case is not covered
+ <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??))
+ <pinotree> gnu_srs1: we do
+ <pinotree> but only for accept4, not for socket and socketpair
+ <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in
+ __libc_accept4()
+ <pinotree> gnu_srs1: no, you need SOCK_*
+ <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and
+ it uses O_* for flags ?
+ <pinotree> flags = sock_to_o_flags (flags);
+ <pinotree> tried checking it?
+ <gnu_srs1> Aha, tks:-D
+ <pinotree> and you don't need an explicit case of O_CLOEXEC, since
+ it is handled in other ways
+ [[!message-id ""]].
+ IRC, freenode, #hurd, 2013-09-03:
+ <gnu_srs> any ideas about the SOCK_CLOEXEC issue?
+ <pinotree> didn't i tell already about it?
+ <gnu_srs> I did not find any hurd related code in tschwinges
+ branches.
+ <pinotree> you didn't check deep then...
+ <gnu_srs> so why does socket/socketpair not return ENOSYS then?
+ <pinotree> why should it, since they are implemented?
+ <braunr> ...
+ <gnu_srs> for socket/socketpair?
+ <braunr> gnu_srs: enosys means no system call
+ <gnu_srs> s/ENOSYS/EINVAL/
+ <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info
+ <gnu_srs> and tschwinges reply
+ <pinotree> which is what i knew already?
+ <gnu_srs> pinotree: please reply on the mailing list on the EINVAL
+ vs EPROTOTYPE issue to clarify things
+ <pinotree> gnu_srs:
+ <pinotree> gnu_srs: things were clear already...
+ <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c
+ returns EPROTOTYPE not changed by the __socket wrapper in eglibc
+ <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends
+ are NOT posix?
+ <gnu_srs> since socket/socketpair does not return EINVAL the dbus
+ code has to be patched then?
+ <pinotree> pflocal should never ever get such flags mixed to the
+ protocol, so any invalid value of protocol correctly returns
+ <gnu_srs> this is the question I need answered: Which way to go?
+ <pinotree> all of them
+ <gnu_srs> ?
+ <pinotree> - applications should not assume that because you have
+ accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK
+ (flags for it) are usable to socket and socketpair
+ <pinotree> - glibc should (as the idea of my patch) handle
+ implementations providing SOCK_* but not supporting them for
+ socket/socketpair
+ <pinotree> - finally the hurd part of glibc could implement them
+ <gnu_srs> to conclude: should I send a bug report for dbus then?
+ <gnu_srs> pinotree: yes or no?
+ <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream*
+ report (not a debian one)
+ IRC, freenode, #hurd, 2013-09-06:
+ <gnu_srs> I've found another error code issue, now in glib2.0 (and
+ dbus). Are you really sure the error code
+ <gnu_srs> for protocol of pflocal/pf.c should be
+ EPROTONOSUPPORT. The code expects EINVAL for a protocol with
+ <gnu_srs> SOCK_CLOEXEC, which is a flag. Maybe pf.c should add
+ this case and return EINVAL instead of
+ <gnu_srs> submitting bug reports upstream. Yes, I know this is not
+ POSIX, but it is defined for Hurd too,
+ <gnu_srs> currently only supported for accept4, not socket or
+ socketpair.
+ <pinotree> gnu_srs: no, and i explained already why it is wrong
+ this way
+ <pinotree> pflocal shouldn't even get such flags
+ <pinotree> (pflocal or any other server implementing socket_create)
+ <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such
+ flags
+ <gnu_srs> then the glibc wrapper code is missing to catch this
+ flag:(
+ <gnu_srs> youpi: ?
+ <pinotree> gnu_srs: because, as told many times, socket and
+ socketpair do not support such flags
+ <pinotree> given they don't do, they filter nothing
+ <pinotree> and no, you need to file bugs upstream, since having
+ SOCK_* and accept4 does not imply at all that socket and
+ socketpair support them
+ IRC, freenode, #hurd, 2013-09-07:
+ <gnu_srs> A correction from yesterdays discussion:
+ IRC, freenode, #hurd, 2013-09-10:
+ <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case
+ needs a patch too (more working tests),
+ <gnu_srs> the updated patch is at if
+ you have the time, otherwise I'll do it.
+ <pinotree> gnu_srs: which is what i wrote in my bug report...
+ <gnu_srs> Yes you wrote that, but the patch is not updated yet?
+ <pinotree> it refers to a different socket access, recently added,
+ which is not used by default
+ <gnu_srs> I got two more tests running when adding that patch:-/
+ <pinotree> tests of what?
+ <gnu_srs> and
+ <pinotree> tests of what?
+ <pinotree> i don't have the universal knowledge of the files in all
+ the sources
+ <gnu_srs> dbus-1.6.14/test/name-test/*
+ [[!message-id ""]].
+ IRC, OFTC, #debian-hurd, 2013-09-19:
+ <pinotree> tschwinge: ehm, regarding the SOCK_* patches for
+ socket/socketpair, didn't we talk about them when i worked on
+ eglibc 2.17?
For specific packages:
* [[octave]]
* Create `t/cleanup_kernel-features.h`.
- * Add tests from Linux kernel commit messages for `t/dup3` et al.
+ * [[Secure_file_descriptor_handling]].
* In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of
`-DHAVE_SENDFILE` -- but we do have `sendfile`, too.
@@ -927,6 +1518,31 @@ Last reviewed up to the [[Git mirror's 0323d08657f111267efa47bd448fbf6cd76befe8
<tschwinge> Yeah, that's known for years... :-D
<tschwinge> Probably not too difficult to resolve, though.
+ * IRC, OFTC, #debian-hurd, 2013-08-16:
+ <pinotree> ← _hurd_thread_sigstate calls
+ malloc, boom
+ * `conformtest`
+ IRC, OFTC, #debian-hurd, 2013-09-22:
+ <youpi> btw, I noticed that glibc has a head conformance test which we
+ happily fail quite a bit :)
+ <youpi> it's not so awful, we don't have twice as many failures as
+ linux, but not so far
+ <pinotree> youpi: do you mean "header" for "head", right?
+ <youpi> err, where ? :)
+ <pinotree> <youpi> btw, I noticed that glibc has a head conformance
+ test which we happily fail quite a bit :)
+ <youpi> ah, yes
+ <pinotree> noticed that too
+ <youpi> I had a quick look at the POSIX part, some things are probably
+ not too hard to change (e.g. exposing pthread_kill in signal.h)
+ <youpi> others will by quite hard to fix (short type instead of int
+ type for some flock structure field)
+ <youpi> s/by/be/
* Verify baseline changes, if we need any follow-up changes:
* a11ec63713ea3903c482dc907a108be404191a02
@@ -1253,6 +1869,13 @@ TODO.
[[!message-id ""]].
+ IRC, freenode, #hurd, 2013-08-27:
+ < gnu_srs> Hi, is this fixed by now?
+ < gnu_srs> ../hurd/hurd.h:72:5: warning: case value ‘0’ not in
+ enumerated type ‘error_t’ [-Wswitch]
+ < pinotree> nope
* baseline
(or probably Samuel's mmap backport) introduces:
diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index 9886ec98..2ef2c474 100644
--- a/open_issues/glibc/debian.mdwn
+++ b/open_issues/glibc/debian.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -24,6 +24,43 @@ locale stuff.
+## IRC, freenode, #hurd, 2013-08-28
+ <youpi> uh, the i686 profiles have much more progression than i386
+ <youpi> it seems they don't actually run these
+ <pinotree> youpi: what do you mean with "we don't run those"?
+ <pinotree> iirc there are three build profiles done, but there are 4
+ regression test files
+ <youpi> yes, but some failing tests are not run in the three build profiles
+ <youpi> even if they are built for all of them
+ <pinotree> not even run? which ones?
+ <youpi> see for instance test-ifloat.out
+ <youpi> test-ifloat is built in all profiles, but only run in the libc one
+ <pinotree> don't have a glibc built tree around atm, sorry :/
+ <youpi> perhaps because glibc thinks it's not useful to run it again if it
+ fails on i386
+ <youpi> you can check the logs
+ <pinotree> do you think glibc's build system is that smart? :)
+ <pinotree> all the builds are done in separate builddirs, so theorically
+ they should not touch each other...
+ <youpi> yes
+ <youpi> that's why I'm surprised
+ <pinotree> could it be they get not run in optimized/particular builds?
+ <pinotree> what about linux/kfreebsd i386?
+ <youpi> I don't see what makes them not run
+ <youpi> or at least be treated particularly by th eMakefile
+ <youpi> not run on kfreebsd either
+ <youpi> pinotree: also, most of the tests now working have been marked as
+ failing by your patches for 2.17, would it be possible to retry them on
+ the box you used at that time?
+ <pinotree> that's the vm on my machine
+ <youpi> which kind of vm?
+ <youpi> kvm?
+ <pinotree> y
+ <youpi> they are working here
+ <youpi> with kvm
# Building
Run `debian/rules patch` to apply patches (instead of having it done during the
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
index 609d866b..7ce36f41 100644
--- a/open_issues/glibc/t/tls-threadvar.mdwn
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -76,3 +76,43 @@ dropped altogether, and `__thread` directly be used in glibc.
<youpi> tschwinge: yes, there were a lot other occurences of threadvars
stuff in various places
<youpi> I'm building libc again, and will see what issue would remain
+## IRC, freenode, #hurd, 2013-07-12
+ <youpi> braunr: about the per-thread ports, there is also the mig reply
+ port
+ <youpi> (stored in _HURD_THREADVAR_MIG_REPLY)
+## IRC, freenode, #hurd, 2013-07-15
+ <braunr> and with the branch youpi pushed where he removes threadvars, it
+ shouldn't get "too" hard
+ <braunr> (save for the tricky bugs you may encounter)
+ <youpi> well, that branch is not working yet
+## IRC, OFTC, #debian-hurd, 2013-09-22
+ <youpi> I'm currently tracking bugs with my threadvars changes
+ <youpi> some of them seem fine, others, not
+ <youpi> of course the most complex ones are the most probable culprits for
+ the issues I'm getting
+ <youpi> fortunately they're after the process bootstrap
+ <youpi> so basically that works
+ <youpi> just a few dozen tests fail
+ <youpi> mostly about loading .so or raising signals
+ <youpi> dlopen(""): cannot open
+ shared object file: Function not implemented
+ <youpi> after having changed errno a bit
+ <youpi> doesn't that look odd ? :)
+ <youpi> good, I found an issue with the sigstate
+ <youpi> now running testsuite again, to see whether there are other issues
+ with it :)
+ <youpi> s/sigstate/reply_port/ actually
+## IRC, OFTC, #debian-hurd, 2013-09-23
+ <youpi> yay, errno threadvar conversion success
diff --git a/open_issues/hurd_init.mdwn b/open_issues/hurd_init.mdwn
new file mode 100644
index 00000000..b0b58a70
--- /dev/null
+++ b/open_issues/hurd_init.mdwn
@@ -0,0 +1,216 @@
+[[!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
+[[!tag open_issue_hurd]]
+# [[!message-id ""]]
+## IRC, freenode, #hurd, 2013-07-22
+ <teythoon> ok, so back to the drawing board for the next big issue, the
+ potential proc and init merge
+ <teythoon> Roland had some harsh words for that proposal, but noone else
+ raised concerns
+ <youpi> noone else does not mean much
+ <youpi> I guess only Roland actually understands the matter
+ <youpi> so I'd tend to believe him
+ <teythoon> even though, his criticism was so superficial, he could at least
+ be a bit more specific...
+ <braunr> i agree that the argument, being simply based on vague principle,
+ isn't very convincing
+ <teythoon> so, what should I do?
+ <braunr> you can either keep them separate, or fight with roland
+ <teythoon> common braunr, I need a little more guidance in these kind of
+ social issues
+ <teythoon> a statement like this is of little use ;)
+ <braunr> that's the best i can give you
+ <teythoon> :/
+ <braunr> i have one patch "fixing" HZ on the hurd, and i even get to fight
+ about it
+ <teythoon> I understand Roland has been around forever and keeps an eye on
+ stuff
+ <teythoon> but could/would he block a patch for hurd if e.g. youpi would
+ accept it
+ <teythoon> i.e. how much control has he in practice?
+ <teythoon> me fighting with him over a patch is of little value for anyone
+ and I don't care to do so
+ <braunr> not much i suppose now
+ <braunr> but we also have to agree with the change
+ <braunr> with *real* arguments
+ <braunr> (well, if it was up to me, i'd even merge exec with proc so ..)
+ <teythoon> ok, so I whip up a patch to see how it goes in practice and
+ present it so we could talk about the issue with something to look at
+ first
+ <braunr> although maybe not ;p
+ <braunr> you'll hit the same reaction
+ <teythoon> from Roland?
+ <braunr> yes
+ <braunr> and youpi said he tends to trust what roland says
+ <braunr> so let's discuss the pros and cons a bit more
+ <teythoon> yes, but I'd honor his concerns if they were properly
+ presented. just telling me to hack on linux instead even though I think I
+ have demonstrated that I do want to work on Hurd is so childish in my
+ eyes that I do not consider that a valid argument at the moment
+ <teythoon> sure, shoot
+ <braunr> well, functionally, they're unrelated
+ <teythoon> head -n1 init/init.c
+ <teythoon> /* Start and maintain hurd core servers and system run state
+ <youpi> and thus it makes sense to make them separate, even if it does not
+ seem to bring anything useful now
+ <youpi> history has shown that it makes a bed for nice things later
+ <braunr> teythoon: that's not what proc is about
+ <teythoon> braunr: I know
+ <teythoon> braunr: that's what init is about in its own words ;)
+ <youpi> teythoon: also, "simplifying the code" is not necessarily an
+ argument that would be considered
+ <youpi> depending on the simplification
+ <youpi> linux made it all simple by using a monolithic kernel :)
+ <youpi> separating concerns is complex
+ <youpi> but in the end it usually pays off on the Hurd
+ <youpi> personally, I'd be fine with Guillem's solution, and renumbering
+ init's pid in Debian
+ <youpi> there's a pending question from Roland actually: what information
+ is exchanged between init and proc in the end?
+ <youpi> that's actually the point of the discussion: is that information
+ really big or not
+ <teythoon> I'm sorry, you lost me, where did he ask that question?
+ <pinotree> $ git grep proc_getmsgport | egrep '[0-9]' ← /hurd/init as pid 1
+ is hardcoded in few places
+ <youpi> teythoon: he didn't ask it this way, but that's the question I had
+ to be able to answer his
+ <youpi> Date: Mon, 15 Jul 2013 10:36:35 -0700 (PDT)
+ <youpi> > That's not what he said. He said there is a lot of information
+ <youpi> > propagated from init to proc, and thus the separation is
+ questionable.
+ <youpi> Are you talking about bootstrap, or what?
+ <youpi> as I haven't investigated much, I couldn't answer this
+ <youpi> pinotree: right. We could patch these in Debian
+ <teythoon> youpi: so, shall I refresh, test and refine Guillems patch and
+ resend it?
+ <youpi> it's probably an easier way
+ <teythoon> ok, I start by doing that
+## IRC, freenode, #hurd, 2013-07-25
+ <teythoon> pinotree: btw, there are two /sbin/init processes even with my
+ hacked up init/proc variant where /sbin/init gets to be pid 1
+ <pinotree> never seen that
+ <pinotree> what are their parents?
+ <teythoon> pinotree: well, pid 1 is /sbin/init now, pid 13 or something has
+ the parent 1
+ <teythoon> looks like init forks or something
+ <pinotree> i guess your sysvinit is compiled without INITDEBUG?
+ <pinotree> nothing in syslog either?
+ <teythoon> pinotree: it's compiled like the sysvinit shipped with debian
+ <pinotree> teythoon: do you have custom additions in inittab?
+ <teythoon> pinotree: a terminal for my serial console
+ <teythoon> *getty
+ <pinotree> are the getty started correctly for you, btw?
+ <teythoon> pinotree: yes
+ <pinotree> interesting
+ <pinotree> teythoon: back then, they were costantly respawning, with hurd's
+ getty's failing to start when exec'ed by (sysv)init
+ <pinotree> wonder what changed
+ <teythoon> pinotree: cool, magically went away then :)
+## IRC, freenode, #hurd, 2013-07-29
+ <teythoon> youpi: I need some feedback on the not freezing translators
+ issue, more specifically whether I understood you correctly in your mail
+ from wednesday (
+ <teythoon> oh yeah, and I had some questions yesterday too, about rpctrace
+ and dead-name notifications, specifically why /hurd/init is not receiving
+ any for the root translator and the exec server
+ <braunr> teythoon: more details please
+ <teythoon> ok, so /hurd/init is registering for dead name notifications for
+ essential tasks
+ <teythoon> the rootfs and exec both register as essential tasks at init and
+ init requests successfully dead name notifications for them
+ <teythoon> if you e.g. kill the auth server, /hurd/init will notice and
+ crash the system
+ <teythoon> if you kill exec or the rootfs, /hurd/init does not get notified
+ <teythoon> I verified this with gdb and an subhurd
+ <teythoon> I'm puzzled by this, as the kernel is the one who sends the
+ notifications, right?
+ <braunr> yes
+ <braunr> teythoon: where is the problem ?
+ <teythoon> and it is not that the system is not sending any messages, it
+ is, I see the msgcount increase over time
+ <teythoon> braunr: dunno, as far as I can tell the kernel does not deliver
+ the notification for rootfs and exec
+ <braunr> oh
+ <teythoon> those are the two processes loaded by grub, maybe they are
+ different somehow
+ <braunr> is that affecting your work ?
+ <teythoon> no, not directly, I strayed around at the weekend, trying to
+ think of cool stuff hurd could do
+ <teythoon> youpi: I need some feedback on the not freezing translators
+ issue, more specifically whether I understood you correctly in your mail
+ from wednesday (
+ <youpi> teythoon: ok, now I'm available for the not-freezing-translators
+ thing :)
+## IRC, freenode, #hurd, 2013-08-05
+ <teythoon> youpi: I'm in the process of producing a unified
+ sysvinit-as-pid1 and please-dont-kill-important-processes patch series
+ <teythoon> youpi: there is one issue with changing /hurd/inits pid, libcs
+ reboot() also assumes that it has the pid 1
+ <youpi> argl
+ <youpi> that's bad, because it's then an ABI, not just an internal thing
+ <teythoon> hardcoding the pid is the worst way of getting a handle of any
+ server :/
+ <teythoon> I've been thinking to make it explicit by binding it to
+ /servers/startup or something
+ <youpi> that would be more hurdish than using a pid, yes
+ <teythoon> yes, and not only does it break the abi, but in a bad way
+ too. if the libc is updated before the hurd, the shutdown sequence is
+ broken in a way that the translators aren't synced :/
+ <teythoon> youpi: as a workaround, we could make reboot() signal both pid 1
+ and 2
+ <youpi> at worse pid 1 shouldn't get harmed by receiving a startup_reboot
+ RPC indeed
+ <teythoon> yes
+## IRC, freenode, #hurd, 2013-08-16
+ <teythoon> grml, the procfs hardcodes the kernels pid :/
+ <teythoon> there's always one more thing to fix...
+ <teythoon> uh, and we made pids.h a private header, so no nice constant for
+ the procfs translator :/
+ <teythoon> server lookup by hardcoding the pid should be banned...
+## IRC, freenode, #hurd, 2013-09-16
+ <teythoon> youpi: I'm thinking about splitting /hurd/init into /hurd/init
+ and /hurd/startup
+ <teythoon> that way, you could also merge the init as pid1 patches
+ <teythoon> that should be doable within the week
+ <youpi> that would probably be better received by Roland than merging init
+ into proc :)
+ <teythoon> yes, I suppose so :D
+ <youpi> perhaps you should start the discussion on the list about it
+ already, with just a sketch of which would do what
+ <teythoon> ok
+ <teythoon> fwiw I like the name startup b/c it speaks the startup protocol
+ <braunr> teythoon: +1 startup
+## IRC, freenode, #hurd, 2013-09-23
+ <teythoon> I've been hacking on init/startup, I've looked into cleaning it
+ up
diff --git a/open_issues/libnetfs_passive_translators.mdwn b/open_issues/libnetfs_passive_translators.mdwn
new file mode 100644
index 00000000..db4c9005
--- /dev/null
+++ b/open_issues/libnetfs_passive_translators.mdwn
@@ -0,0 +1,55 @@
+[[!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
+[[!tag open_issue_hurd]]
+# IRC, freenode, #hurd, 2013-07-15
+ <teythoon> is there a libnetfs based translator that supports passive
+ translators?
+ <youpi> I don't see any at the top of my head, only with active ones such
+ as hostmux
+ <teythoon> I suspected as much since as far as I can tell libnetfs lacks
+ some bits to make that even work
+ <braunr> teythoon: the problem with passive translators is persistence
+ <braunr> well, it's easy to store volatile passive translators in a
+ libnetfs server
+ <braunr> but usually, there is no backing store for them
+ <braunr> ext2fs is the only one actually providing space to store their
+ command line
+ <teythoon> sure, but at least file_get_translator needs to work so that
+ procfs can serve a mounts node
+ <braunr> silly idea but
+ <braunr> don't you want to directly add it to the procfs translator ?
+ <teythoon> no, I think it's useful on its own
+ <braunr> ok
+ <braunr> then you may need to add the required support
+ <teythoon> it even doubles as normal command line tool
+ <teythoon> yes, I almost got it... or so I hope ;)
+ <braunr> ok
+ <teythoon> also, netfs_get_translator exists, so not supporting that feels
+ like a bug to me
+ <teythoon> could also be useful for a potential devfs translator
+ <braunr> yes
+ <teythoon> uh, the code duplication in lib*fs is really bad :/
+ <teythoon> the code is mostly similar, though they have diverged and many
+ little things are different so diffing them is very noisy
+ <teythoon> stuff like file names or identifiers
+ <teythoon> and I cannot figure out why my shiny passive translators are not
+ started :/
+ <teythoon> % showtrans tmp/mounts
+ <teythoon> /hurd/mtab.fixed /
+ <teythoon> % wc --bytes tmp/mounts
+ <teythoon> 0 tmp/mounts
+ <teythoon> and no mtab translator around either
diff --git a/open_issues/libnetfs_argument_parsing.mdwn b/open_issues/libnetfs_vs_libdiskfs.mdwn
index e1e0d794..2fcfbea5 100644
--- a/open_issues/libnetfs_argument_parsing.mdwn
+++ b/open_issues/libnetfs_vs_libdiskfs.mdwn
@@ -10,7 +10,12 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_hurd]]
-# IRC, freenode, #hurd, 2013-06-27
+# Argument Parsing
+## IRC, freenode, #hurd, 2013-06-27
<teythoon> the arg parsing in libdiskfs and libnetfs differ :/
<teythoon> afaics libdiskfs gets it right, libnetfs does not
@@ -60,3 +65,54 @@ License|/fdl]]."]]"""]]
<teythoon> whee, remounting proc works :)
<braunr> :)
+# IRC, freenode, #hurd, 2013-07-29
+ <teythoon> so, what do you folks think about refactoring libdiskfs and
+ libnetfs to be more alike?
+ <pinotree> what do you mean?
+ <teythoon> ah, I mentioned that in the context of my mtab prototype
+ <teythoon> they are hard to diff against each other b/c they differ in file
+ names and identifier names
+ <teythoon> while working on the mtab stuff I encountered stuff that was
+ implemented in libdiskfs, but never in libnetfs
+ <teythoon> mostly support for binding translators to libnetfs nodes
+ <braunr> teythoon: sure, but looks a little out of scope
+ <teythoon> braunr: I do not mean now, more in general
+ <braunr> ok
+ <tschwinge> teythoon: I wondered about this, too. I don't know if it's
+ possible to literally merge them (and build the backend-based (libdiskfs)
+ vs. volatile-backend one (libnetfs) based on a pre-processor define or
+ similar), or just structure the source code (files) in a way such that
+ »diff -ru libdiskfs/ libnetfs/« gives meaningful results, figuratively
+ spoken.
+ <teythoon> tschwinge: my thoughts exactly
+# IRC, freenode, #hurd, 2013-08-28
+ <teythoon> braunr: do you think another lib*fs would be frowned uppon? I
+ like the way procfs is structured and that could be refactored and
+ generalized into a library
+ <braunr> i think we need more lib*fs libraries
+ <braunr> and better integration
+ <braunr> that's one of the strengths in linux
+ <braunr> it makes writing file systems very easy
+ <teythoon> cool :)
+ <teythoon> now we only need a snappy name, any suggestions?
+ <braunr> i don't know what you like specificlaly in procfs
+ <braunr> libpseudofs ?
+ <teythoon> well, it's not perfect, but i like the way you just have to
+ implement a function for a node and it magically gains the ability to
+ being read
+ <teythoon> for example
+ <braunr> yes i see
+ <pinotree> lacks a bit of caching though
+ <braunr> no caching for such file systems
+ <teythoon> indeed
+ <braunr> why would you want caching ?
+ <pinotree> you might have files that don't change at all, or rarely do
+ <braunr> the premise is that it's meant for files generated on the fly
+ <braunr> but are they big ?
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index 8e3fde71..0b426884 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -974,7 +974,7 @@ Most of the issues raised on this page has been resolved, a few remain.
<braunr> exec weights 164M eww, we definitely have to fix that leak
<braunr> the leaks are probably due to wrong mmap/munmap usage
### IRC, freenode, #hurd, 2012-08-29
diff --git a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
index 4e35161f..6f09ea0d 100644
--- a/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
+++ b/open_issues/libpthread/t/fix_have_kernel_resources.mdwn
@@ -196,3 +196,220 @@ Address problem mentioned in [[/libpthread]], *Threads' Death*.
## IRC, freenode, #hurd, 2013-07-03
<braunr> grmbl, i don't want to give up thread destruction ..
+## IRC, freenode, #hurd, 2013-07-15
+ <braunr> btw, my work on thread destruction is currently stalled
+ <braunr> i don't have much free time right now
+## IRC, freenode, #hurd, 2013-09-13
+ <braunr> i think i know why my thread_terminate_deallocate patches leak one
+ receive port :>
+ <braunr> but now i'm not sure of the proper solution
+ <braunr> every time a thread is created and destroyed, a receive right is
+ leaked
+ <braunr> i guess it's simply the reply port ..
+ <braunr> grmbl
+ <braunr> i guess i have to make it a simpleroutine ...
+ <braunr> hm too bad, it's not the reply port :(
+ <braunr> it's also leaking some memory
+ <braunr> it doesn't seem related to my changes though
+ <braunr> stacks, rights, and threads are correctly destroyed
+ <braunr> some obscure state is left behind
+ <braunr> i wonder how exception ports are dealt with
+ <braunr> vminfo seems to confirm memory is leaking in the heap
+ <braunr> humpf
+ <braunr> oh silly me
+ <braunr> i don't detach threads
+ <teythoon> well, detach them ;)
+ <braunr> hm worse :p
+ <braunr> now i get additional dead names
+ <braunr> but it's a step forward
+## IRC, freenode, #hurd, 2013-09-16
+ <braunr> that thread port leak is so strange
+ <braunr> the leaked port seems to be created when the new thread starts
+ running
+ <braunr> so it looks like a port the kernel would implicitely create
+ <braunr> hm could it be a thread-specific reply port ?
+ <youpi> ah, yes, there is one of those
+ <braunr> how come mach/mig-reply.c in glibc isn't thread-safe ?
+ <youpi> it is overriden by sysdeps/mach/hurd/img-reply.c I guess
+ <youpi> which uses a threadvar for the mig reply port
+ <braunr> oh
+ <youpi> talking of which, there is also last_value in
+ sysdeps/mach/strerror_l.c
+ <youpi> strerror_thread_freeres is supposed to get called, but who knows
+ <braunr> it does look to be that port
+ <youpi> iirc that's the issue which prevents from letting us make threads
+ exit on idleness?
+ <braunr> one of them
+ <youpi> ok
+ <braunr> maybe the only one, yes
+ <braunr> i see memory leaks but they could be related/normal
+ <braunr> (i.e. not actual leaks)
+ <braunr> on the other hand, i also can't boot a hurd with my patch
+ <braunr> but i consider removing such leaks a priority
+ <braunr> does anyone know the semantic difference between
+ __mig_put_reply_port and __mig_dealloc_reply_port ?
+ <braunr> i guess __mig_dealloc_reply_port is actually a destruction
+ operation, right ?
+ <youpi> AIUI, dealloc is used when one wants the port not to be reused at
+ all
+ <youpi> because it has been used as a reference for something, and can
+ still be currently in use
+ <youpi> while put_reply would be when we're really done with it, and won't
+ use it again, and can thus be used as such
+ <youpi> or at least something like that
+ <braunr> heh
+ <braunr> __mig_dealloc_reply_port calls __mach_port_mod_refs, which is a
+ RPC, and creates a new reply port when destroying the current one
+ <youpi> bah
+ <youpi> that's fine, it's a deref of the old port, which is not in the
+ reply_port variable any more
+ <braunr> it's fine, but still a leak
+ <youpi> well, dealloc does not completely deallocs, yes
+ <braunr> that's not really the problem here
+ <braunr> i've introduced a case that wasn't considered at the time, namely
+ that a thread can destroy itself
+ <youpi> we probably need another function to be called from the thread exit
+ <braunr> i'll simply try with mach_port_destroy
+ <braunr> mach_port_destroy seems to be a RPC too ...
+ <braunr> grmbl
+ <youpi> isn't there a trap version somehow ?
+ <braunr> not in libc
+ <youpi> erf
+ <braunr> at least i know what's wrong now :)
+ <braunr> there still is a small memory leak i have to investigate
+ <braunr> but outside the stack
+ <braunr> the stack, the thread name and the thread are correctly destroyed
+ <braunr> slabinfo confirms only one port leak and nothing else is leaked
+ <braunr> ok so the port leak was indeed the thread-specific reply port,
+ taken care of
+ <braunr> there are also memory leaks too
+## IRC, freenode, #hurd, 2013-09-17
+ <braunr> teythoon: on my side, i'm getting to know our threading
+ implementation better
+ <braunr> closing to clean thread destruction
+ <braunr> x15 ipc will hide reply ports ;p
+ <braunr> memory leaks solved \o/
+ <braunr> now, have to fix memory release when joining
+ <braunr> proper reference counting on detach/join/exit, let's see how it
+ goes ..
+ <braunr> seems to work fine
+## IRC, freenode, #hurd, 2013-09-18
+ <braunr> ok i'll soon have gnumach and libc packages including proper
+ thread destruction :>
+ <teythoon> braunr: why did you have to touch gnumach?
+ <braunr> to add a call allowing threads to release ports and memory
+ <braunr> i.e. their last self reference, their reply port and their stack
+ <braunr> let me public my current patches
+ <teythoon> braunr: thread_commit_suicide ?
+ <braunr> hehe
+ <braunr> initially thread_terminate_self but
+ <braunr> it can be used by other threads too
+ <braunr> to i named it thread_terminate_release
+ <braunr>
+ <braunr>
+ <braunr> the pthread patch needs to be polished because it changes the
+ semantics of pthread_thread_halt
+ <braunr> but other than that, it should be complete
+ <pinotree> pthread_thread_halt_reallyhalt
+ <braunr> ok let's try these libc packages
+ <braunr> old static ext2fs for the root, but other than that, it boots
+ <braunr> let's try iceweasel
+ <braunr> (i'll need to build a hurd package against this new libc, removing
+ the libports_stability patch which prevents thread destruction in servers
+ on the way)
+ <teythoon> prevents thread destruction o_O
+ <braunr> yes
+ <braunr> in libports only ;p
+ <teythoon> oh, *only* in libports, I assumed for a moment that it affected
+ almost every component of the Hurd...
+ <teythoon> *phew(
+ <braunr> ... :)
+ <braunr> that's why, after a burst of messages, say because of aptitude
+ (select), you may see a few hundred threads still hanging around
+ <braunr> also why unused servers remain running even after several minutes,
+ where the normal timeout is 2mins
+ <teythoon> I wondered about that, some servers (symlink comes to mind) seem
+ to go away if unused (or that's how I read the code)
+ <braunr> symlinks are usually not servers, since most of them actually
+ exist in file systems, and are implemented through an optimization
+ <teythoon> yes I know that
+ <teythoon> trans/symlink.c reads:
+ <teythoon> /* The timeout here is 10 minutes */
+ <teythoon> err = mach_msg_server_timeout (fsys_server, 0, control,
+ <teythoon> MACH_RCV_TIMEOUT, 1000 * 60 * 10);
+ <teythoon> if (err == MACH_RCV_TIMED_OUT)
+ <teythoon> exit (0);
+ <braunr> ok
+ <teythoon> hm, /hurd/symlink doesn't feel at all like a symlink... but
+ works like one
+ <braunr> well, starting iceweasel makes X on my host freeze oO
+ <braunr> bbl
+ <teythoon> /hurd/symlink translators do go away after being unused for 10
+ minutes... this is funny if they are set up by hand instead of being
+ started from a passive translator record
+ <teythoon> magically vanishing symlinks ;)
+## IRC, freenode, #hurd, 2013-09-19
+ <braunr> hum, i can't rebuild a hurd package :(
+ <teythoon> braunr: with your thread destruction patches in libc?
+ <braunr> yes but it's unrelated
+ <braunr> In file included from ../../libdiskfs/boot-start.c:38:0:
+ <braunr> ./fsys_reply_U.h:173:15: error: conflicting types for
+ ‘fsys_get_children’
+ <braunr> i didn't see a new libc debian release
+ <teythoon> hm, David reported that as well
+ <teythoon>
+ <teythoon> uh oh
+ <teythoon> it seems I didn't add a _reply suffix to the reply routines :/
+ <teythoon> there's quite a bit of fallout from my patches, I kinda feel bad
+ :(
+ <braunr> teythoon: what i'm wondering is what youpi did too, since he got
+ hurd binary packages
+ <teythoon> braunr: well neither he nor I noticed that b/c for us the
+ declarations were just missing
+ <braunr> from libc you mean ?
+ <braunr> or hum gnumach-common ?
+ <teythoon> not sure actually
+ <braunr> no it's not a gnumach thing
+ <braunr> hurd-dev then
+ <teythoon> the build system should have cought these, or mig...
+ <braunr> also, i see you changed fsys_reply.defs, but nothing about
+ fsys_request.defs
+ <teythoon> I have no fsys_requests.defs
+ <braunr> looks like there was no fsys_request.defs in the first place
+ ... *sigh*
+ <braunr> do you know an application that often creates and destroys threads
+ ?
+ <teythoon> no, sorry
+ <pinotree> maybe some test suite
+ <braunr> ah right
+ <braunr> sysbench maybe
+ <braunr> also, i've been hit by a lot more network deadlocks than usual
+ lately
+ <braunr> fixing netdde has gained some priority in my todo list
+## IRC, freenode, #hurd, 2013-09-20
+ <braunr> oh, git is multithreaded
+ <braunr> great
+ <braunr> so i've actually tested my libpthread patch quite a lot
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
index 05a07ef2..5d574261 100644
--- a/open_issues/libpthread_dlopen.mdwn
+++ b/open_issues/libpthread_dlopen.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -112,7 +113,18 @@ IRC, freenode, #hurd, 2011-08-17
+# IRC, freenode, #hurd, 2013-09-03
+ <gnu_srs> iceweasel: ./pthread/../sysdeps/generic/pt-mutex-timedlock.c:70:
+ __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
+ <pinotree> LD_PRELOAD libpthread
+ <gnu_srs> why
+ <pinotree> missing link to pthread?
+ <pinotree> and yes, it's known already, just nobody worked on solving it
+# libthreads vs. libpthread
The same symptom appears in an odd case, for instance:
diff --git a/open_issues/llvm.mdwn b/open_issues/llvm.mdwn
index 30b18edf..4da58579 100644
--- a/open_issues/llvm.mdwn
+++ b/open_issues/llvm.mdwn
@@ -101,6 +101,35 @@ a06fe9183fbffb78798a444da9bc3040fdd444aa (2013-03-23), test-suite
A lot of Linux-specific things.
+ * IRC, OFTC, #debian-hurd, 2013-09-05:
+ <gg0> how can this fix it on {kf,hurd}-i386?
+ <pinotree> what makes you think it does?
+ <pinotree> it fixes #714890, which has nothing to do with hurd or
+ kfreebsd
+ <gg0> i simple wouldn't add a patch that fixes it on one i386 arch
+ only, being aware there are others
+ <pinotree> meet sylvestre
+ * IRC, freenode, #hurd, 2013-09-05:
+ <pinotree> tschwinge: iirc you were working on llvm/clang, weren't you?
+ <tschwinge> pinotree: That's right. I have patches to
+ follow-up/rework. Stalled at the moment, as you probably already
+ guessed... %-)
+ <pinotree> tschwinge: <Sylvestre> by the way, pinotree if you have time
+ for hurd stuff, I would be glad to have your help to port
+ llvm-toolchain-3.3 to hurd. I am having some issues with threading
+ aspects
+ <pinotree> he's the debian packager of llvm
+ <tschwinge> That paste is for LLDB -- which I'd not assume to be in a
+ shape usable for Hurd.
+ <tschwinge> (I didn't look at it at all.)
+ <pinotree> tschwinge: if you look at the latest llvm-toolchain-3.3
+ debian source, there's a lldb-hurd.diff patch, which starts some
+ include header dance
# Build
diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn
index c14ce95a..bbc6ac45 100644
--- a/open_issues/mach_migrating_threads.mdwn
+++ b/open_issues/mach_migrating_threads.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -15,3 +15,89 @@ License|/fdl]]."]]"""]]
* [[microkernel/mach/memory_object/discussion]]
* [[resource_management_problems]]
+# IRC, freenode, #hurd, 2013-08-13
+In context of [[resource_management_problems]].
+ <braunr> and thread migration itself is something very confusing
+ <braunr> it's better to think of it as scheduling context inheritance
+ <teythoon> braunr: I read the paper I mentioned and then I wanted to find
+ the sources they modified
+ <teythoon> I failed
+ <teythoon> I hate scientific paper about software that fail to provide the
+ source code
+ <teythoon> that's not science imho b/c it's not reproducible
+ <braunr> i have some osf source code here
+ <braunr> i'll send it if you want
+ <teythoon> ah interesting
+ <braunr> but really, when you dive into it, thread migration is merely
+ scheduling context inheritance with kernel upcalls
+ <braunr> it's good
+ <teythoon> I searched for osf mach but google didn't turned up anything
+ <braunr> but it has nothing to do with resource accounting
+ <braunr> (well, it may hepl better account for cpu time actually)
+ <braunr> help*
+ <braunr> but that's all
+ <teythoon> why is that all? wouldn't that be transitive and could also be
+ used for i/o accounting?
+ <teythoon> also I tried to find alternative mach implementations
+ <teythoon> I wasn't terribly successful, and some sites are gone or
+ unmaintained for years :/
+ <braunr> we don't need that for io accountin
+ <braunr> g
+ <braunr> thread migration is a kernel property
+ <braunr> on mach with userspace drivers, io isn't
+ <braunr> mach should only control cpu and memory
+ <braunr> and you though you can account physical memory, you can't transfer
+ virtual memory accounting from one task to another
+ <teythoon> yes, but once all of those resources can be accounted to the
+ thread initiating whatever it needs doing, shouldn't that be much easier?
+ <braunr> teythoon: it's not required for that
+ <braunr> teythoon: keep in mind userspace sees activations
+ <braunr> in a thread migration enabled kernel, activations are what we
+ usually call threads, and threads are scheduling contexts
+ <teythoon> braunr: ok, so TM is not required for accounting, but surely
+ it's a good thing to have, no?
+ <braunr> teythoon: it's required for cpu accounting only
+ <braunr> which is very important :)
+ <braunr> if you look carefully, you'll see hurd servers are what use most
+ cpu
+ <braunr> there is now easy way to know which application actually uses the
+ server
+ <braunr> i personally tend to think more and more that servers *should*
+ impersonate clients
+ <braunr> TM (or rather, scheduling context inheritance) is one step
+ <braunr> it's not enough exactly because it doesn't help with resource
+ accounting
+ <braunr> teythoon:
+# IRC, freenode, #hurd, 2013-09-02
+[[!taglink open_issue_documentation]]: move information to
+ <teythoon> braunr: btw, I just noticed lot's of #ifdef MIGRATING_THREADS in
+ gnumach, so there was some work being done in that direction?
+ <braunr> gnumach is a fork of mach4
+ <braunr> at a stage whre migration was being worked on, yes
+ <teythoon> from what I've gathered, gnumach is the only surviving mach4
+ fork, right?
+ <braunr> yes
+ <braunr> well
+ <braunr> the macos x version is probably one too
+ <braunr> i don't know
+ <teythoon> oh? I read that it was based on mach3
+ <braunr> it is
+ <braunr> i can't tell how much of mach3 versus mach4 it has, and if it's
+ relevant at all
+ <teythoon> and the osfmach, was that also based on mach4?
+ <braunr> yes
+ <teythoon> ok, fair enough
+ <braunr> that's why i think macos x is based on it too
+ <braunr> i initially downloaded osfmach sources to see an example of how
+ thread migration was used from userspace
+ <braunr> and they do have a special threading library for that
diff --git a/open_issues/memory_object_model_vs_block-level_cache.mdwn b/open_issues/memory_object_model_vs_block-level_cache.mdwn
index 7da5dea4..22db9b86 100644
--- a/open_issues/memory_object_model_vs_block-level_cache.mdwn
+++ b/open_issues/memory_object_model_vs_block-level_cache.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2012, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_documentation open_issue_hurd open_issue_gnumach]]
# IRC, freenode, #hurd, 2012-02-14
@@ -271,3 +273,242 @@ License|/fdl]]."]]"""]]
<mcsim> slpz: When mo_data_return is called, once the memory manager no
longer needs supplied data, it should be deallocated using
vm_deallocate. So this way pagers acknowledges the end of flush.
+# IRC, freenode, #hurd, 2013-08-26
+ < Spyro> Ok, so
+ < Spyro> idiot question: in a nutshell, what is a memory object?
+ < Spyro> and how is swapping/paging handled?
+ < braunr> Spyro: a memory object is how the virtual memory system views a
+ file
+ < braunr> so it's a sequence of bytes with a length
+ < braunr> "swapping" is just a special case of paging that applies to
+ anonymous objects
+ < braunr> (which are named so because they're not associated with a file
+ and have no name)
+ < Spyro> Who creates a memory object, and when?
+ < braunr> pagers create memory objects when needed, e.g. when you open a
+ file
+ < Spyro> and this applies both to mmap opens as well as regular I/O opens
+ as in for read() and write()?
+ < braunr> basically, all file systems capable of handling mmap requests
+ and/or caching in physical memory are pagers
+ < braunr> yes
+ < braunr> read/write will go through the page cache when possible
+ < Spyro> and who owns the page cache?
+ < Spyro> also, who decides what pages ot evict to swap/file if physical
+ memory gets tight?
+ < braunr> the kernel
+ < braunr> that's one of the things that make mach a hybrid
+ < Spyro> so the kernel owns the page cage?
+ < Spyro> ...fml
+ < Spyro> cache!
+ < braunr> yes
+## IRC, freenode, #hurd, 2013-08-27
+ < Spyro> so braunr: So, who creates the memory object, and how does it get
+ populated?
+ < Spyro> and how does a process accessing a file get hooked up to the
+ memory object?
+ < braunr> Spyro: i told you, pagers create memory objects
+ < braunr> memory objects are how the VM system views files, so they're
+ populated from the content of files
+ < braunr> either true files or virtual files such as in /proc
+ < braunr> Spyro: processes don't directly access memory objects unless
+ memory mapping them with vm_map()
+ < braunr> pagers (basically = file systems) do
+ <Spyro> ok, so how is a pager/fs involved in handling a fault?
+## IRC, freenode, #hurd, 2013-08-28
+ <braunr> Spyro: each object is linked to a pager
+ <braunr> Spyro: when a fault occurs, the kernel looks up the VM map (kernel
+ or a user one), and the address in this map, then the map entry, checks
+ access and lots of other details
+ <Spyro> ok, so it's pager -> object -> vmem
+ <Spyro> ?
+ <braunr> Spyro: then finds the object mapped at that address (similar to
+ how a file is mapped with mmap)
+ <braunr> from the object, it finds the pager
+ <Spyro> ok
+ <braunr> and asks the pager about the data at the appropriate offset
+ <Spyro> so how does a user process do normal file I/O? is faulting just a
+ special case of it?
+ <braunr> it's completely separate
+ <Spyro> eww
+ <braunr> normal I/O is done with message passing
+ <braunr> the hurd io interface
+ <Spyro> ok
+ <Spyro> so who talks to who on a file I/O?
+ <braunr> a client (e.g. cat) talks to a file system server (e.g. ext2fs)
+ <Spyro> ok so
+ <Spyro> it's client to the pager for regular file I/O?
+ <braunr> Spyro: i don't understand the question
+ <braunr> Spyro: it's client to server, the server might not be a pager
+ <Spyro> ok
+ <Spyro> just trying to figure out the difference between paging/faulting
+ and regular I/O
+ <braunr> regular I/O is just message passing
+ <braunr> page fault handling is dealt with by pagers
+ <Spyro> and I have a hunch that the fs/pager is involved somehow in both,
+ because the server is the source of the data
+ <Spyro> I'm getting a headache
+ <braunr> nalaginrut: a server like ext2fs is both a file server and a pager
+ <Spyro> oh!
+ <Spyro> oh btw, does a file server make use of memory objects for caching?
+ <braunr> Spyro: yes
+ <Spyro> or rather, can it?
+ <Spyro> does it have to?
+ <braunr> memory objects are for caching, and thus for page faults
+ <braunr> Spyro: for caching, it's a requirement
+ <braunr> for I/O, it's not
+ <braunr> you could have I/O without memory objects
+ <Spyro> ok
+ <Spyro> so how does the pager/fileserver use memory objects for caching?
+ <Spyro> does it just map and write to them?
+ <braunr> basically yes but there is a complete protocol with the kernel for
+ that
+ <braunr>
+ <Spyro> heh, lucky guess
+ <Spyro> ty
+ <Spyro> I am in way over my head here btw
+ <Spyro> zero experience with micro kernels in practice
+ <braunr> it's not trivial
+ <braunr> that's not a microkernel thing at all
+ <braunr> that's how it works in monolithic kernels too
+ <braunr> i recommend netbsd uvm thesis
+ <braunr> there are nice pictures describing the vm system
+ <Spyro> derrr...preacious?
+ <Spyro> wow
+ <braunr> just ignore the anonymous memory handling part which is specific
+ to uvm
+ <Spyro> @_@
+ <braunr> the rest is common to practically all VM systems out there
+ <Spyro> I know about the linux page cache
+ <braunr> well it's almost the same
+ <Spyro> with memory objects being the same thing as files in a page cache?
+ <braunr> memory objects are linux "address spaces"
+ <braunr> and address spaces are how the linux mm views a file, yes
+ <Spyro> derp
+ <Spyro> ...
+ <Spyro> um...
+ <braunr> struvt vm_page == struct page
+ * Spyro first must learn what an address_space is
+ <braunr> struct vm_map == struct mm_struct
+ <braunr> struct vm_map_entry == struct vm_area_struct
+ * Spyro isn't a linux kernel vm expert either
+ <braunr> struct vm_object == struct address_space
+ <braunr> roughly
+ <braunr> details vary a lot
+ <Spyro> and what's an address_space ?
+ <braunr> 11:41 < braunr> and address spaces are how the linux mm views a
+ file, yes
+ <Spyro> ok
+ <braunr> see include/linux/fs.h
+ <braunr> struct address_space_operations is the pager interface
+ * Spyro should look at the linux kernel sources perhaps, unless you have an
+ easier reference
+ <Spyro> embarrassingly, RVR hired me as an editor for the linux-mm wiki
+ <Spyro> I should know this stuff
+ <braunr> see
+ <braunr> page 42
+ <braunr> page 66 for another nice view
+ <braunr> i wouldn't recommend using linux source as refernece
+ <braunr> it's very complicated, filled with a lot of code dealing with
+ details
+ <Spyro> lmao
+ <braunr> and linux guys have a habit of choosing crappy names
+ <Spyro> I was only going to
+ <Spyro> stoppit
+ <braunr> except for "linux" and "git"
+ <Spyro> ...make me laugh any more and I'll need rib surgery
+ <braunr> laugh ?
+ <Spyro> complicated and crappy
+ <braunr> seriously, "address space" for a file is very very confusing
+ <Spyro> oh I agree with that
+ <braunr> yes, names are crappy
+ <braunr> and the code is very complicated
+ <braunr> it took me half an hour to find where readahead is done once
+ <braunr> and i'm still not sure it was the right code
+ <Spyro> so in linkern, there is an address_space for each cached file?
+ <braunr> takes me 30 seconds in netbsd ..
+ <braunr> yes
+ <Spyro> eww
+ <Spyro> yeah, BAD name
+ <Spyro> but thanks for the explanation
+ <Spyro> now I finally know what an address space is
+ <braunr> many linux core developers admit they don't care much about names
+ <Spyro> so, in hurd, a memory object is to hurd, what an address_space is
+ to linux?
+ <braunr> yes
+ <braunr> notto hurd
+ <Spyro> ok
+ <braunr> to mach
+ <Spyro> you know what I mean
+ <Spyro> :P
+ <Spyro> easier than for linux I can tell you that much
+ <braunr> and the bsd vm system is a stripped version of the mach vm
+ <Spyro> ok
+ <braunr> that's why i think it's important to note it
+ <Spyro> good, I learned something abou tthe linux vm...from the mach guys
+ <Spyro> this is funny
+ <braunr> linux did too
+ <braunr> there is a paper about linux page eviction that directly borrows
+ the mach algorithm and improves it
+ <braunr> mach is the historic motivation behind mmap on posix
+ <Spyro> oh nice!
+ <Spyro> but yes, linux picked a shitty name
+ <braunr> is all that clearer to you ?
+ <Spyro> I think that address_space connection was a magic bolt of
+ understanding
+ <braunr> and do you see how I/O and paging are mostly unrelated ?
+ <Spyro> almost
+ <Spyro> but how does a file I/O take advantage of caching by a memory
+ object?
+ <Spyro> does the file server just nudge the core for a hint?
+ <braunr> the file system copies from the memory object
+ * Spyro noddles
+ <Spyro> I think I understand a bit better now
+ <braunr> it's message passing
+ <Spyro> but I havfe too much to digest already
+ <braunr> memory copying
+ <braunr> if the memory is already there, good, if not, the kernel will ask
+ the file system to bring the data
+ <braunr> if message passing uses zero copy, data retrieval can be deferred
+ until the client actually accesses it
+ <Spyro> which is a fancy way of saying demand paging? :P
+ <braunr> it's always demand paging
+ <braunr> what i mean is that the file system won't fetch data as soon as it
+ copies memory
+ <braunr> but when this data is actually needed by the client
+ <Spyro> uh...
+ <Spyro> whta's a precious page?
+ <braunr> let me check quickly
+ <braunr> If precious is FALSE, the kernel treats the data as a temporary
+ and may throw it away if it hasn't been changed. If the precious value is
+ TRUE, the kernel treats its copy as a data repository and promises to
+ return it to the manager
+ <braunr> basically, it's used when you want the kernel to keep cached data
+ in memory
+ <braunr> the cache becomes a lossless container for such pages
+ <braunr> the kernel may flush them, but not evict them
+ <Spyro> what's the difference?
+ <braunr> imagine a ramfs
+ <Spyro> point made
+ <braunr> ok
+ <Spyro> would be pretty hard to flush something that doesn't have a backing
+ store
+ <braunr> that was quick :)
+ <braunr> well
+ <braunr> the normal backing store for anonymous memory is the default pager
+ <braunr> aka swap
+ <Spyro> eww
+ <braunr> but if you want your data *either* in swap or in memory and never
+ in both
+ <braunr> it may be useful
diff --git a/open_issues/mig_portable_rpc_declarations.mdwn b/open_issues/mig_portable_rpc_declarations.mdwn
index 084d7454..91838f60 100644
--- a/open_issues/mig_portable_rpc_declarations.mdwn
+++ b/open_issues/mig_portable_rpc_declarations.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -56,3 +56,114 @@ License|/fdl]]."]]"""]]
<antrik> braunr: we discussed the problem of expressing structs with MIG in
the libburn thread
<antrik> (which I still need to follow up on... [sigh])
+# IRC, freenode, #hurd, 2013-06-25
+ <teythoon> is there a nice way to get structured data through mig that I
+ haven't found yet?
+ <teythoon> say an array of string triples
+ <braunr> no
+ <teythoon> :/
+ <braunr> but you shouldn't need that
+ <teythoon> my use case is getting info about fs translators from init to
+ procfs
+ <teythoon> should I go for an iterator like interface instead?
+ <braunr> depends
+ <braunr> how many do you need ?
+ <braunr> you could go for a variable sized array too
+ <braunr> have a look at what already exists
+ <teythoon> records, maybe 10-15, depends on many fs translators are running
+ <braunr> a variable sized array is ok if the size isn't too big (and when i
+ say too big, i mean hundreds of MiB)
+ <braunr> an iterator is ok too if there aren't too many items
+ <braunr> you may want to combine both (i think that's what proc does)
+ <braunr> be aware that the maximum size of a message is limited to 512 MiB
+ <teythoon> yeah I saw the array[] of stuff stuff, but array[] of string_t
+ does not work, I guess b/c string_t is also an array
+ <teythoon> how would I send an array of variable length strings?
+ <braunr> i'm not sure you can
+ <braunr> or maybe out of line
+ <teythoon> somehow I expected mig to serialize arbitrary data structures,
+ maybe it's to old for that?
+ <teythoon> yeah, I read about uot of line, but that seems overkill
+ <braunr> it is old yes
+ <braunr> and not very user friendly in the end
+ <braunr> let me check
+ <teythoon> we could stuff json into mig...
+ <braunr> see proc_getallpids for example
+ <braunr> we could get rid of low level serialization altogether :p
+ <teythoon> hah, exactly what I was looking at
+ <braunr> (which is what i'll do in x15)
+ <braunr> type pidarray_t = array[] of pid_t;
+ <teythoon> but that is trivial b/c its array[] of pid_t
+ <braunr> and always have the server writing guide near you
+ <teythoon> yes
+ <braunr> well, make one big string and an array of lengths :p
+ <teythoon> thought about that and said to myself, there must be a better
+ way that I haven't found yet
+ <braunr> or one big string filled with real null-terminated c strings that
+ you keep parsing until you ate all input bytes
+ <braunr> i'm almost certain there isn't
+ <braunr> type string_t = c_string[1024]; /* XXX */
+ <teythoon> yes
+ <braunr> even that isn't really variable sized
+ <teythoon> you think anyone would object to me putting a json encoder in
+ /hurd/init? it is probably better than me at serializing stuff...
+ <braunr> try with mig anyway
+ <braunr> the less dependencies we have for core stuff, the simpler it is
+ <braunr> but i agree, mig is painful
+ <teythoon> would it be too hacky if I abused the argz functions? they do
+ exactly what I'd need
+## IRC, freenode, #hurd, 2013-06-26
+ <teythoon> there is and it has a rpc
+ mechanism and I believe one could plug arbitrary transports easily
+ <braunr> please don't think about it
+ <braunr> we really don't want to add another layer of serialization
+ <braunr> it's better to completely redesign mach ipc anyway
+ <braunr> and there is a project for that :p
+ <teythoon> ive seen x15
+ <teythoon> just food for thought
+ <braunr> i've studied google protocol buffers
+ <braunr> and fyi, no, it wouldn't be easy to plug arbitrary transports on
+ top of mach
+ <braunr> there is a lot of knowledge about mach ports in mig
+ <teythoon> but again I face the challenge of serializing a arbitrary sized
+ list of arbitrary sized strings
+ <braunr> yes
+ <teythoon> list of ports is easier ;) but I think its worthwile
+ <teythoon> so what about abusing argz* for this? you think it's too bad a
+ hack?
+ <braunr> no since it's in glibc
+ <teythoon> awesome :)
+ <braunr> but i don't remember the details well and i'm not sure the way you
+ use it is safe
+ <teythoon> yeah, I might have got the details wrong, I hadn't had the
+ chance to test it ;)
+ <braunr> about this dynamic size problem
+ <braunr> a "simple" varying size array should do
+ <braunr> you can easily put all your strings in there
+ <teythoon> seperated by 0?
+ <braunr> yes
+ <teythoon> that's exactly what the argz stuff does
+ <braunr> you'll get the size of the array anyway, and consume it until
+ there is no byte left
+ <braunr> good
+ <braunr> but be careful with this too
+ <braunr> since translators can be run by users, they somtimes can't be
+ trusted
+ <braunr> and even a translator running as root may behave badly
+ <braunr> so careful with parsing
+ <teythoon> noted
diff --git a/open_issues/mig_stub_functions.mdwn b/open_issues/mig_stub_functions.mdwn
new file mode 100644
index 00000000..24a582b1
--- /dev/null
+++ b/open_issues/mig_stub_functions.mdwn
@@ -0,0 +1,41 @@
+[[!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
+[[!tag open_issue_mig]]
+# RPC Stubs Implemented by Hand
+## IRC, freenode, #hurd, 2013-07-28
+ <teythoon> why is libfshelp/start-translator-long.c doing the fsys_startup
+ rpcs by hand instead of using the mig generated stubs?
+## IRC, freenode, #hurd, 2013-07-29
+ <teythoon> btw, anyone knows why libfshelp/start-translator-long.c
+ implements the fsys_startup rpc by hand?
+ <braunr> teythoon: no idea
+ <teythoon> maybe b/c of the need to specify a timeout? can one do that with
+ the mig stubs?
+ <braunr> yes
+ <braunr> select used to be implemented that way
+# Generate the Request and Reply Routines from the Synchronous Routines
+## IRC, freenode, #hurd, 2013-09-19
+ <teythoon> btw, is there any reason why mig couldn't generate the request
+ and reply routines from the synchronous routines?
+ <braunr> i guess it could
diff --git a/open_issues/nptl.mdwn b/open_issues/nptl.mdwn
index 9ff5fb51..3c84bfb0 100644
--- a/open_issues/nptl.mdwn
+++ b/open_issues/nptl.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
@@ -10,7 +10,10 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_libpthread open_issue_glibc]]
-IRC, #hurd, 2010-07-31
+# IRC, freenode, #hurd, 2010-07-31
<tschwinge> Other question: how difficult is a NPTL port? Futexes and some kernel interfaces for scheduling stuff etc. -- what else?
<youpi> actually NPTL doesn't _require_ futexes
@@ -26,6 +29,21 @@ IRC, #hurd, 2010-07-31
<tschwinge> ... and even less so the interfavce that actual applications are using.
<tschwinge> We'd need to evaluate which benefits NPTL would bring.
+# IRC, freenode, #hurd, 2013-08-05
+ <gnu_srs> Hi, looks like kfreebsd are now using an NPTL-based pthread
+ library: FBTL,
+ <gnu_srs> Anything of interest for porting to Hurd? See also
+ <azeem> Petr could've been more verbose in his announcements
+ <pinotree> and there's
+ in our wiki
+ <azeem> well, it seems to work fine for kFreeBSD:
+ <azeem> and
# Resources
diff --git a/open_issues/pthread_atfork.mdwn b/open_issues/pthread_atfork.mdwn
index ac724cf0..1b656f05 100644
--- a/open_issues/pthread_atfork.mdwn
+++ b/open_issues/pthread_atfork.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -8,6 +8,13 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
-[[!tag open_issue_libpthread]]
+[[!tag open_issue_glibc open_issue_libpthread]]
-pthread_atfork is not actually implemented, making some programs fail. Code can probably be borrowed from nptl/sysdeps/unix/sysv/linux/register-atfork.c
+`pthread_atfork` is not actually implemented, making some programs fail. Code
+can probably be borrowed from `nptl/sysdeps/unix/sysv/linux/register-atfork.c`.
+# IRC, OFTC, #debian-hurd, 2013-08-21
+ <pinotree> SRCDIR/opal/mca/memory/linux/arena.c:387: warning: warning:
+ pthread_atfork is not implemented and will always fail
diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn
index 8f752d61..daf97954 100644
--- a/open_issues/resource_management_problems.mdwn
+++ b/open_issues/resource_management_problems.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -61,7 +61,8 @@ This is, of course, non-trivial to implement, and also requires changing the
-IRC, freenode, #hurd, 2011-07-31
+## IRC, freenode, #hurd, 2011-07-31
< braunr> one of the biggest problems on the hurd is that, when a client
makes a call, kernel (and other) resources are allocated on behalf of the
@@ -75,6 +76,20 @@ IRC, freenode, #hurd, 2011-07-31
+## IRC, freenode, #hurd, 2013-08-13
+In context of <>.
+ <braunr> teythoon: actually, thread migration isn't required for resource
+ accounting
+ <teythoon> braunr: but it solves it for free, doesn't it?
+ <braunr> teythoon: no
+ <braunr> it's really more complicated than that
# Further Examples
* [[hurd/critique]]
@@ -83,4 +98,34 @@ IRC, freenode, #hurd, 2011-07-31
* [[translators_set_up_by_untrusted_users]], and [[pagers]]
- * [[configure max command line length]]
+ * [[configure_max_command_line_length]]
+## [[hurd/translator/exec]] server
+### IRC, freenode, #hurd, 2013-08-05
+ <teythoon> unzipping stuff in the exec server enables a dos on filesystem
+ translators
+ <teythoon> is
+ /hurd/hello padded with a gig of zeros, compressed with bzip2
+ <teythoon> if set as an passive translator, it stalls other requests to the
+ filesystem, at least it does if ext2fs is used
+ <braunr> teythoon: ?
+ <braunr> teythoon: what's the dos here ?
+ <teythoon> I can prevent you from doing anything with the root filesystem
+ <teythoon> I'm kind of surprised myself, maybe a lock is held during the
+ exec of the translator?
+ <teythoon> the filesystem the hello-1g.bz2 translator is bound to is
+ affected
+ <braunr> teythoon: i don't understand
+ <braunr> have you tried starting something from another file system ?
+ <braunr> the lock may simply be in the exec server itself
+ <teythoon> no, starting other things works fine
+ <teythoon> but on the other hand, a find / is stalled
+ <braunr> :/
+ <braunr> *sigh*
+ <teythoon> don't worry
+ <teythoon> there is a solution :p
+ <braunr> :)
+ <teythoon> and it only requires deleting code
diff --git a/open_issues/robustness.mdwn b/open_issues/robustness.mdwn
index 1f8aa0c6..a6b0dbfb 100644
--- a/open_issues/robustness.mdwn
+++ b/open_issues/robustness.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -10,6 +10,7 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_documentation open_issue_hurd]]
# IRC, freenode, #hurd, 2011-11-18
@@ -32,7 +33,9 @@ License|/fdl]]."]]"""]]
<etenil> ah yeah I thought so :)
-# IRC, freenode, #hurd, 2011-11-19
+# Reincarnation Server
+## IRC, freenode, #hurd, 2011-11-19
<chromaticwt> will hurd ever have the equivalent of a rs server?, is that
even possible with hurd?
@@ -127,3 +130,40 @@ License|/fdl]]."]]"""]]
<spiderweb> neat, thanks
<braunr> actually it's not that old at all
<braunr> around 2007
+## IRC, freenode, #hurd, 2013-08-26
+ < teythoon> I came across some paper about process reincarnation and
+ created a little prototype a while back:
+ < teythoon>
+ < teythoon> and I looked into restarting the exec server in case it
+ dies. the exec server is an easy target since it has no state of its own
+ < teythoon> the only problem is that there is no exec server around to
+ start a new one
+ < youpi> teythoon: there could be another exec server only used to
+ (re)start the exec server
+ < youpi> that other exec server could even be restarted by the normal exec
+ server
+ < pinotree> what about a watchdog server?
+ < teythoon> youpi: yes, I had the same idea, i actually patched /hurd/init
+ to do that, it's just not yet working
+ < pinotree> make it watch other servers (exec included), and make exec
+ watch the watchdog only
+ < teythoon> pinotree: look at my prototype, there is a watchdog server
+ < braunr> teythoon: what's the point of reincarnation without persistence ?
+ < teythoon> braunr: there is no point in reincarnation w/o persistence of
+ course
+ < teythoon> my prototype does a limited form of persistence
+ < teythoon> the point was to see whether I can mitm a translator and
+ restart it on demand and to gain more insight into the whole translator
+ mechanism
+ < braunr> teythoon: ok
+ < teythoon> braunr: see the readme, it retains state across reincarnations
+ < braunr> teythoon: how ?
+ < teythoon> braunr: the server can store a checkpoint using the
+ reincarnation_checkpoint procedure
+ < teythoon>
+ < teythoon> uh >,< sorry, pasted twice
+ < braunr> oh ok
diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn
index 45e983a7..f4d1d396 100644
--- a/open_issues/secure_file_descriptor_handling.mdwn
+++ b/open_issues/secure_file_descriptor_handling.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation,
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -16,7 +17,7 @@ on this, posted patches to [[mailing_lists/libc-alpha]]. This works needs to
be resumed
and finished.
+Add tests from Linux kernel commit messages for `t/dup3` et al.
In <> an interesting point is made: *you [may]
want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you
diff --git a/open_issues/systemd.mdwn b/open_issues/systemd.mdwn
index c23f887f..d00b3d8a 100644
--- a/open_issues/systemd.mdwn
+++ b/open_issues/systemd.mdwn
@@ -102,6 +102,939 @@ Likely there's also some other porting needed.
<braunr> just assume you can't use systemd on anything else than linux
+## IRC, OFTC, #debian-hurd, 2013-08-12
+ <azeem> huh, Lennert Poettering just mentioned the Hurd in his systmd talk
+ <azeem> well, in the context of you IPC in Unix sucks and kdbus
+ <azeem> s/you/how/
+ <pinotree> QED
+ <pinotree> what did you expect? :)
+ <azeem> I didn't quite get it, but he seemed to imply the Hurd was a step
+ in the right direction over Unix
+ <azeem> (which is obvious, but it wasn't obvious he had that opinion)
+## IRC, OFTC, #debian-hurd, 2013-08-13
+ <azeem> so cgroups seems to be most prominent thing the systemd people
+ think the Hurd lacks
+ <tschwinge> azeem: In 2010, I came to the same conclusion,
+ <>. ;-)
+ <azeem> heh
+ <tschwinge> I don't think of any show-stopper for implementing that -- just
+ someone to do it.
+ <youpi> azeem: which part of cgroups, like being able to kill a cgroup?
+ <youpi> it shouldn't be very hard to implement what systemd needs
+ <azeem> probably also the resource allocation etc.
+ <azeem> the questions are I guess (i) do the cgroups semantics make sense
+ from our POV and/or do we accept that cgroups is the "standard" now and
+ (ii) should systemd require concrete implementations or just the concept
+ in a more abstract sense
+ <teythoon> being the first non Linux OS that runs systemd would be a nice
+ showcase of Hurds flexibility
+ <azeem> maybe upstart is less trouble
+ <pinotree> azeem: possibly
+ <azeem> teythoon: can you just include upstart in your GSOC? kthxbye
+ <pinotree> at least libnih (the library with base utilities and such used
+ by upstart) required a working file monitor (and the current
+ implementation kind of exposes a fd) and certain semantics for waitid
+ <pinotree> libnih/upstart have "just" the issue of being under CLA...
+ <azeem> pinotree: yeah, true
+ <azeem> I suggested "startup" as a name for a fork
+ <pinotree> imho there would be no strict need to fork
+ <teythoon> azeem: but upstart is a lot less interesting. last time I used
+ it it wasn't even possible to disable services in a clean way
+ <pochu> pinotree: is that still so now that Scott works for google?
+ <pinotree> pochu: yeah, since it's a Canonical CLA, not rally something
+ tied to a person
+ <pinotree> (iirc)
+ <pochu> sure, but scott is the maintainer...
+ <pochu> shrug
+ <azeem> nah, scott left upstart
+ <azeem> AFAIK
+ <azeem> at least James Hunt gave a talk earlier with Steve Langasek and
+ introduced himself as the upstart maintainer
+ <azeem> also I heard in the hallway track that the upstart people are
+ somewhat interested in BSD/Hurd support as they see it as a selling point
+ against systemd
+ <pinotree> pochu: it's just like FSF CLA for GNU projects: even if the
+ maintainers/contributors change altogether, copyright assignment is still
+ <azeem> but their accents were kinda annoying/hard to follow so I didn't
+ follow their talk closesly to see whether they brought it up
+ <azeem> pinotree: well, it's not
+ <pochu> azeem: looking at, I'm not sure
+ libnih has a maintainer anymore...
+ <azeem> pinotree: first off, you're not signing over the copyright with
+ their CLA, just giving them the right to relicense
+ <azeem> pinotree: but more importantaly, the FSF announced in a legally
+ binding way that they will not take things non-free
+ <azeem> anyway, I'll talk to the upstart guys about libnih
+## IRC, OFTC, #debian-hurd, 2013-08-15
+ <azeem> btw, I talked to vorlon about upstart and the Hurd
+ <azeem> so the situation with libnih is that it is basically
+ feature-complete, but still maintained by Scott
+ <azeem> upstart is leveraging it heavily
+ <azeem> and Scott was (back in the days) against patches for porting
+ <azeem> for upstart proper, Steve said he would happily take porting
+ patches
+## IRC, freenode, #hurd, 2013-08-26
+ < youpi> teythoon: I tend to agree with mbanck
+ < youpi> although another thing worth considering would be adding something
+ similar to control groups
+ < youpi> AIUI, it's one of the features that systemd really requires
+ < braunr> uhg, cgroups already
+ < braunr> youpi: where is that discussion ?
+ < youpi> it was a private mail
+ < braunr> oh ok
+ < teythoon> right, so about upstart
+ < teythoon> to be blunt, I do not like upstart, though my experience with
+ it is limited and outdated
+ < braunr> that was quick :)
+ < braunr> i assume this follows your private discussion with youpi and
+ mbank ?
+ < teythoon> I used it on a like three years old ubuntu and back then it
+ couldn't do stufft hat even sysvinit could do
+ < teythoon> there was not much discussion, mbank suggested that I could
+ work on upstart
+ < teythoon> b/c it might be easier to support than systemd
+ < teythoon> which might be very well true, then again what's the benefit of
+ having upstart? I'm really curious, I should perhaps read up on its
+ features
+ < pinotree> event-based, etc
+ < youpi> it is also about avoiding being pushed out just because we don't
+ support it?
+ < teythoon> yes, but otoh systemd can do amazing things, the featurelist of
+ upstart reads rather mondane in comparison
+ < youpi> I don't really have an opinion over either, apart from portability
+ of the code
+ < braunr> teythoon: the system requirements for systemd would take much
+ time to implement in comparison to what we already have
+ < braunr> i still have maksym's work on last year gsoc on my list
+ < braunr> waiting to push in the various libpager related patches first
+ < teythoon> so you guys think it's worthwile to port upstart?
+ < braunr> no idea
+ < braunr> teythoon: on another subject
+ < azeem_> teythoon: I like systemd more, but the hallway track at Debconf
+ seemed to imply most people like Upstart better except for the CLA
+ < azeem_> which I totally forgot to address
+ < youpi> CLA ?
+ < azeem_> contributor license agreement
+ < braunr> since you've now done very good progress, is your work available
+ in the form of ready-to-test debian packages ?
+ < teythoon> braunr: it is
+ < teythoon> braunr:
+ < braunr> i remember urls in some of your mails
+ < braunr> ah thanks
+ < braunr> "cryptobitch" hum :)
+ < azeem_> in any case, everbody assumed either Upstart or Systemd are way
+ ahead of systemvinit
+ < braunr> sysvinit is really ancient :)
+ < azeem_> apart from the non-event-driven fundamental issue, a lot of
+ people critized that the failure rate at writing correct init-scripts
+ appears to be too high
+ < azeem_> one of the questions brought up was whether it makes sense to
+ continue to ship/support systemvinit once a switch is made to
+ systemd/upstart for the Linux archs
+ < azeem_> systemvinit scripts might bitrot
+ < azeem_> but anyway, I don't see a switch happen anytime soon
+ < teythoon> well, did upstart gain the capability of disabling a service
+ yet?
+ < azeem_> teythoon: no idea, but apparently:
+ < teythoon> azeem_: then there is hope yet ;)
+ < azeem_> the main selling point of Upstart is that it shipped in several
+ LTS releases and is proven technology (and honestly, I don't read a lot
+ of complaints online about it)
+ < azeem_> (I don't agree that SystemD is unproven, but that is what the
+ Upstart guys implied)
+ < teythoon> am I the only one that thinks that upstart is rather
+ unimpressive?
+ * azeem_ doesn't have an opinion on it
+ < azeem> teythoon:
+ has slides and
+ the video
+ < azeem> teythoon: eh, appears the link to the slides is broken, but they
+ are here:
+ < braunr> teythoon: actually, from the presentation, i'd tend to like
+ upstart
+ < braunr> dependency, parallelism and even runlevel compatibility flows
+ naturally from the event based model
+ < braunr> sysv compatibility is a great feature
+ < braunr> it does look simple
+ < braunr> i admit it's "unimpressive" but do we want an overkill init
+ system ?
+ < braunr> teythoon: what makes you not like it ?
+ < azeem> Lennart critized that upstart doesn't generate events, just
+ listens to them
+ < azeem> (which is a feature, not a bug to some)
+ < braunr> azeem: ah yes, that could be a lack
+ < azeem> braunr:
+ was the corresponding SystemD talk by Lennart, though he hasn't posted
+ slides yet I think
+ < teythoon> braunr: well, last time I used it it was impossible to cleanly
+ disable a service
+ < teythoon> also ubuntu makes such big claims about software they develop,
+ and when you read up on them it turns out that most of the advertised
+ functionality will be implemented in the near future
+ < teythoon> then they ship software as early as possible only to say later
+ that is has proven itself for so many years
+ < teythoon> and tbh I hate to be the one that helped port upstart to hurd
+ (and maybe kfreebsd as a byproduct) and later debian choses upstart over
+ systemd b/c it is available for all debian kernels
+ < kilobug> teythoon: ubuntu has a tendency to ship software too early when
+ it's not fully mature/stable, but that doesn't say anything about the
+ software itself
+ < pinotree> teythoon: note the same is sometimes done on fedora for young
+ technologies (eg systemd)
+ < azeem> teythoon: heh, fair enough
+ < p2-mate> braunr: I would prefer if my init doesn't use ptrace :P
+ < teythoon> p2-mate: does upstart use ptrace?
+ < p2-mate> teythoon: yes
+ < teythoon> well, then I guess there won't be an upstart for Hurd for some
+ time, no?
+ < kilobug> p2-mate: why does it use ptrace for ?
+ < p2-mate> kilobug: to find out if a daemon forked
+ < kilobug> hum I see
+ < azeem> p2-mate: the question is whether there's a Hurdish way to
+ accomplish the same
+ < p2-mate>
+ < p2-mate> see job_process_trace_new :)
+ < kilobug> azeem: it doesn't seem too complicated to me to have a way to
+ get proc notify upstart of forks
+ < p2-mate> azeem: that's a good question. there is a linuxish way to do
+ that using cgroups
+ < azeem> right, there's a blueprint suggesting cgroups for Upstart here:
+ < teythoon> yes, someone should create a init system that uses cgroups for
+ tracking child processes >,<
+ < teythoon> kilobug: not sure it is that easy. who enforces that proc_child
+ is used for a new process? isn't it possible to just create a new mach
+ task that has no ties to the parent process?
+ < teythoon> azeem: what do you mean by "upstart does not generate events"?
+ there are "emits X" lines in upstart service descrpitions, surely that
+ generates event X?
+ < azeem> I think the critique is that this (and those upstart-foo-bridges)
+ are bolted on, while SystemD just takes over your systems and "knows"
+ about them first-hand
+ < azeem> but as I said, I'm not the expert on this
+ < teythoon> uh, in order to install upstart one has to remove sysvinit
+ ("yes i am sure...") and it fails to bring up the network on booting the
+ machine
+ < teythoon> also, both systemd and upstart depend on dbus, so no cookie for
+ us unless that is fixed first, right?
+ < pinotree> true
+ < teythoon> well, what do you want me to do for the next four weeks?
+ < youpi> ideally you could make both upstart and systemd work on hurd-i"86
+ < pinotree> both in 4 weeks?
+ < youpi> so hurd-i386 doesn't become the nasty guy that makes people tend
+ for one or the other
+ < youpi> I said "ideally"
+ < youpi> I don't really have any idea how much work is required by either
+ of the two
+ < youpi> I'd tend to think the important thing to implement is something
+ similar to control groups, so both upstart (which is supposed to use them
+ someday) and systemd can be happy about it
+ < teythoon> looks like upstarts functionality depending on ptrace is not
+ required, but can be enabled on a per service base
+ < teythoon> so a upstart port that just lacks this might be possible
+ < teythoon> youpi: the main feature of cgroups is that a process cannot
+ escape its group, no? i'm not sure how this could be implemented atop of
+ mach in a secure and robust way
+ < teythoon> b/c any process can just create mach tasks
+ < youpi> maybe we need to add a feature in mach itself, yes
+ < teythoon> ok, implementing cgroups sounds fun, I could do that
+ < youpi> azeem: are you ok with that direction?
+ < azeem> well, in general yes; however, AIUI, cgroups is being redesigned
+ upstream, no?
+ < youpi> that's why I said "something like cgroups"
+ < azeem> ah, ok
+ < youpi> we can do something simple enough to avoid design quesetions, and
+ that would still be enough for upstart & systemd
+ < azeem>
+ (
+ btw
+ < braunr> p2-mate: upstart uses ptrace ?
+ < p2-mate> yes
+ < youpi> teythoon: and making a real survey of what needs to be fixed for
+ upstart & systemd
+ < p2-mate> see my link posted earlier
+ < braunr> ah already answered
+ < braunr> grmbl
+ < braunr> it's a simple alternative to cgroups though
+ < braunr> teythoon: dbus isn't a proble
+ < braunr> problem
+ < braunr> it's not that hard to fix
+ < youpi> well, it hasn't been fixed for a long time now :)
+ < braunr> we're being slow, that's all
+ < braunr> and interested by other things
+ < gg0> 12:58 < teythoon> btw, who is this heroxbd fellow and why has he
+ suddenly taken interest in so many debian gsoc projects?
+ < gg0>
+ < gg0> i notice nobody mentioned openrc
+ < pinotree> he's the debian student working on integrating openrc
+ < gg0> pinotree: no, the student is Bill Wang, Benda as he says is a
+ co-mentor
+ < pinotree> whatever, it's still the openrc gsoc
+ < azeem> well, they wanted to look at it WRT the Hurd, did they follow-up
+ on this?
+ < gg0> btw wouldn't having openrc on hurd be interesting too?
+ < pinotree> imho not really
+ < gg0> no idea whether Bill is also trying to figure out what to do,
+ probably not
+ < azeem> somebody could ping that thread you mentioned above to see whether
+ they looked at the Hurd and/or need help/advice
+ < gg0> azeem: yeah somebody who could provide such help/advice. like.. you?
+ for instance
+ * gg0 can just paste urls
+ < azeem> they should just follow-up on-list
+## IRC, freenode, #hurd, 2013-08-28
+ <teythoon> anyone knows a user of cgroups that is not systemd? so far I
+ found libcg, that looks like a promising first target to port first,
+ though not surprisingly it is also somewhat linux specific
+ <taylanub> teythoon: OpenRC optionally uses cgroups IIRC.
+ <taylanub> Not mandatory because unlike systemd it actually tries (at all)
+ to be portable.
+## IRC, freenode, #hurd, 2013-09-02
+ <teythoon> braunr: I plan to patch gnumach so that the mach tasks keep a
+ reference to the task that created them and to make that information
+ available
+ <teythoon> braunr: is such a change acceptable?
+ <braunr> teythoon: what for ?
+ <teythoon> braunr: well, the parent relation is currently only implemented
+ in the Hurd, but w/o this information tracked by the kernel I don't see
+ how I can prevent malicious/misbehaving applications to break out of
+ cgroups
+ <teythoon> also I think this will enable us to fix the issue with tracking
+ which tasks belong to which subhurd in the long term
+ <braunr> ah cgroups
+ <braunr> yes cgroups should partly be implemented in the kernel ...
+ <braunr> teythoon: that doesn't surprise me
+ <braunr> i mean, i think it's ok
+ <braunr> the kernel should implement tasks and threads as closely as the
+ hurd (or a unix-like system) needs it
+ <teythoon> braunr: ok, cool
+ <teythoon> braunr: I made some rather small and straight forward changes to
+ gnumach, but it isn't doing what I thought it would do :/
+ <teythoon> braunr:
+ <braunr> you added a field to task_basic_info
+ <braunr> thereby breaking the ABI
+ <teythoon> braunr: my small test program says: my task port is 1(pid 13)
+ created by task -527895648; my parent task is 31(pid 1)
+ <teythoon> braunr: no, it is not. I appended a field and these structures
+ are designed to be extendable
+ <braunr> hm
+ <braunr> ok
+ <braunr> although i'm not so sure
+ <braunr> there are macros defining the info size, depending on what you ask
+ <braunr> you may as well get garbage
+ <braunr> have you checked that ?
+ <teythoon> i initialized my struct to zero before calling mach
+ <braunr> teythoon: can you put some hardcoded value, just to make sure data
+ is correctly exported ?
+ <teythoon> braunr: right, good idea
+ <teythoon> braunr: my task port is 1(pid 13) created by task 3; my parent
+ task is 31(pid 1) -- so yes, hardcoding 3 works
+ <braunr> ok
+ <teythoon> braunr: also I gathered evidence that the convert_task_to_port
+ thing works, b/c first I did not have the task_reference call just before
+ that so the reference count was lowered (convert... consumes a reference)
+ and the parent task was destroyed
+ <teythoon> braunr: I must admit I'm a little lost. I tried to return a
+ reference to task rather than task->parent_task, but that didn't work
+ either
+ <teythoon> braunr: I feel like I'm missing something here
+ <teythoon> maybe I should get aquainted with the kernel debugger
+ <teythoon> err, the kernel debugger is not accepting any symbol names, even
+ though the binary is not stripped o_O
+ <teythoon> err, neither the kdb nor gdb attached to qemu translates
+ addresses to symbols, gdb at least translates symbols to addresses when
+ setting break points
+ <teythoon> how did anyone ever debug a kernel problem under these
+ conditions?
+ <braunr> teythoon: i'll have a look at it when i have some time
+## IRC, freenode, #hurd, 2013-09-03
+ <teythoon> :/ I believe the startup_notify interface is ill designed... an
+ translator can defer the system shutdown indefinitely
+ <braunr> it can
+ <teythoon> that's bad
+ <braunr> yes
+ <braunr> the hurd has a general tendency to trust its "no mutual trust
+ required" principle
+ <braunr> to rely on it a bit too much
+ <teythoon> well, at least it's a privileged operation to request this kind
+ of notification, no?
+ <braunr> why ?
+ <braunr> teythoon: it normally is used mostly by privileged servers
+ <braunr> but i don't think there is any check on the recipient
+ <teythoon> braunr: b/c getting the port to /hurd/init is done via
+ proc_getmsgport
+ <braunr> teythoon: ?
+ <teythoon> braunr: well, in order to get the notifications one needs the
+ msgport of /hurd/init and getting that requires root privileges
+ <braunr> teythoon: oh ok then
+ <braunr> teythoon: what's bad with it then ?
+ <teythoon> braunr: even if those translators are somewhat trusted, they can
+ (and do) contain bugs and stall the shutdown
+ <teythoon> I think this even happened to me once, I think it was the pfinet
+ translator
+ <braunr> teythoon: how do you want it to behave instead ?
+ <teythoon> braunr: well, /hurd/init notifies the processes sequentially,
+ that seems suboptimal, better to send async notifications to all of them
+ and then to collect all the answers
+ <teythoon> braunr: if one fails to answer within a rather large time frame
+ (say 5 minutes) shutdown anyway
+ <braunr> i agree with async notifications but
+ <braunr> i don't agree with the timeout
+ <teythoon> for reference, a (voluntary) timeout of 1 minute is hardcoded in
+ /hurd/init
+ <braunr> the timeout should be a parameter
+ <braunr> it's common on large machines to have looong shutdown delays
+ <teythoon> of the notification?
+ <braunr> the answer means "ok i'm done you can shutdown"
+ <braunr> well this can take long
+ <braunr> most often, administrators simply prefer to trust their program is
+ ok and won't take longer than it needs to, even if it's long
+ <teythoon> and not answering at all causes the shutdown / reboot to fail
+ making the system hang
+ <braunr> i know
+ <teythoon> in a state where it is not easily reached if you do not have
+ access to it
+ <braunr> but since it only concerns essential servers, it should befine
+ <braunr> essential servers are expected to behave well
+ <teythoon> it concerns servers that have requested a shutdown notification
+ <braunr> ok so no essential but system servers
+ <teythoon> essential servers are only exec, proc, /
+ <teythoon> yes
+ <braunr> the same applies
+ <pinotree> init and auth too, no?
+ <teythoon> yes
+ <braunr> you expect root not to hang himself
+ <teythoon> I do expect all software to contain bugs
+ <braunr> yes but you also expect them to provide a minimum level of
+ reliability
+ <braunr> otherwise you can just throw it all away
+ <teythoon> no, not really
+ <braunr> well
+ <teythoon> I know, that's my dilemma basically ;)
+ <braunr> if you don't trust your file system, you make frequent backups
+ <braunr> if you don't trust your shutdown code, you're ready to pull the
+ plug manually
+ <braunr> (or set a watchdog or whatever)
+ <braunr> what i mean is
+ <braunr> we should NEVER interfere with a program that is actually doing
+ its job just because it seems too long
+ <braunr> timeouts are almost never the best solution
+ <braunr> they're used only when necessary
+ <braunr> e.g. across networks
+ <braunr> it's much much much worse to interrupt a proper shutdown process
+ because it "seems too long" than just trust it behaves well 99999%%%% of
+ the time
+ <braunr> in particular because this case deals with proper data flushing,
+ which is an extremely important use case
+ <teythoon> it's hard/theoretically impossible to distinguish between taking
+ long and doing nothing
+ <braunr> it's impossible
+ <braunr> agreed
+ <braunr> => trust
+ <braunr> if you don't trust, you run real time stuff
+ <braunr> and you don't flush data on disk
+ <teythoon> ^^
+ <braunr> (which makes a lot of computer uses impossible as well)
+ <teythoon> there are only 2 people I trust, and the other one is not
+ /hurd/pfinet
+ <braunr> if this shutdown procedure is confined to the TCB, it's fine to
+ trust it goes well
+ <teythoon> tcb?
+ <braunr> trusted computing base
+ <braunr>
+ * teythoon shudders
+ <teythoon> "trust" is used way to much these days
+ <teythoon> and I do not like the linux 2.0 ip stack to be part of our TCB
+ <braunr> basically, on a multiserver system like the hurd, the tcb is every
+ server on the path to getting a service done from a client
+ <braunr> then make it not request to be notified
+ <braunr> or make two classes of notifications
+ <braunr> because unprivileged file systems should be notified too
+ <teythoon> indeed
+ <teythoon> by the way, we should have a hurdish libnotify or something for
+ this kind of notifications
+ <braunr> but in any case, it should really be policy
+ <braunr> we should ... :)
+ <teythoon> ^^
+## IRC, freenode, #hurd, 2013-09-04
+ <teythoon> braunr: btw, I now believe that no server that requested
+ shutdown notifications can stall the shutdown for more than 1 minute
+ *unless* its message queue is full
+ <teythoon> so any fs should better sync within that timeframe
+ <braunr> where is this 1 min defined ?
+ <teythoon> init/init.c search for 60000
+ <braunr> ew
+ <teythoon> did I just find the fs corruption bug everyone was looking for?
+ <braunr> no
+ <braunr> what corruption bug ?
+ <teythoon> not sure, I thought there was still some issues left with
+ unclean filesystems every now and then
+ <teythoon> *causing
+ <braunr> yes but we know the reasons
+ <teythoon> ah
+ <braunr> involving some of the funniest names i've seen in computer
+ terminology :
+ <braunr> writeback causing "message floods", which in turn create "thread
+ storms" in the servers receiving them
+ <teythoon> ^^ it's usually the other way around, storms causing floods >,,
+ <braunr> teythoon: :)
+ <braunr> let's say it's a bottom-up approach
+ <teythoon> then the fix is easy, compile mach with -DMIGRATING_THREADS :)
+ <braunr> teythoon: what ?
+ <teythoon> well, that would solve the flood/storm issue, no?
+ <braunr> no
+ <braunr> the real solution is proper throttling
+ <braunr> which can stem from synchronous rpc (which is the real property we
+ want from migrating threads)
+ <braunr> but the mach writeback interface is async
+ <braunr> :p
+## IRC, freenode, #hurd, 2013-09-05
+ <braunr> teythoon: oh right, forgot about your port issue
+ <teythoon> don't worry, I figured by now that this must be a pointer
+ <teythoon> and I'm probably missing some magic that transforms this into a
+ name for the receiver
+ <teythoon> (though I "found" this function by looking at the mig
+ transformation for ports)
+ <braunr> i was wondering why you called the convert function manually
+ <braunr> instead of simply returning the task
+ <braunr> and let mig do the magic
+ <teythoon> b/c then I would have to add another ipc call, no?
+ <braunr> let me see the basic info call again
+ <braunr> my problem with this code is that it doesn't take into account the
+ ipc space of the current task
+ <braunr> which means you probably really return the ipc port
+ <braunr> the internal kernel address of the struct
+ <braunr> indeed, ipc_port_t convert_task_to_port(task)
+ <braunr> i'd personally make a new rpc instead of adding it to basic info
+ <braunr> basic info doesn't create rights
+ <braunr> what you want to achieve does
+ <braunr> you may want to make it a special port
+ <braunr> i.e. a port created at task creation time
+ <teythoon> y?
+ <braunr> it also means you need to handle task destruction and reparent
+ <teythoon> yes, I thought about that
+ <braunr> see
+ <braunr> for now you may simply turn the right into a dead name when the
+ parent dies
+ <braunr> although adding a call and letting mig do it is simpler
+ <braunr> mig handles reference counting, users just need to task_deallocate
+ once done
+ <teythoon> o_O mig does reference counting of port rights?
+ <braunr> mig/mach_msg
+ <teythoon> is there anything it *doesn't* do?
+ <braunr> i told you, it's a very complicated messaging interface
+ <braunr> coffee ?
+ <braunr> fast ?
+ <teythoon> ^^
+ <braunr> mig knows about copy_send/move_send/etc...
+ <braunr> so even if it doesn't do reference counting explicitely, it does
+ take care of that
+ <teythoon> true
+ <braunr> in addition, the magic conversions are intended to both translate
+ names into actual structs, and add a temporary reference at the same time
+ <braunr> teythoon: everything clear now ? :)
+ <teythoon> braunr: no, especially not why you suggested to create a special
+ port. but this will have to wait for tomorrow ;)
+## IRC, OFTC, #debian-hurd, 2013-09-06
+ <vorlon> teythoon: hi there
+ <vorlon> so I've been following your blog entries about cgroups on
+ hurd... very impressive :)
+ <vorlon> but I think there's a misunderstanding about upstart and
+ cgroups... your "conjecture" in
+ is
+ incorrect
+ <vorlon> cgroups does not give us the interfaces that upstart uses to
+ define service readiness; adding support for cgroups is interesting to
+ upstart for purposes of resource partitioning, but there's no way to
+ replace ptrace with cgroups for what we're doing
+ <teythoon> vorlon: hi and thanks for the fish :)
+ <teythoon> vorlon: what is it exactly that upstart is doing with ptrace
+ then?
+ <teythoon> .,oO( your nick makes me suspicious for some reason... ;)
+ <teythoon> service readiness, what does that mean exactly?
+ <vorlon> teythoon: so upstart uses ptrace primarily for determining service
+ readiness. The idea is that traditionally, you know an init script is
+ "done" when it returns control to the parent process, which happens when
+ the service process has backgrounded/daemonized; this happens when the
+ parent process exits
+ <vorlon> in practice, however, many daemons do this badly
+ <vorlon> so upstart tries to compensate, by not just detecting that the
+ parent process has exited, but that the subprocess has exited
+ <vorlon> (for the case where the upstart job declares 'expect daemon')
+ <vorlon> cgroups, TTBOMK, will let you ask "what processes are part of this
+ group" and possibly even "what process is the leader for this group", but
+ doesn't really give you a way to detect "the lead process for this group
+ has changed twice"
+ <vorlon> now, it's *better* in an upstart/systemd world for services to
+ *not* daemonize and instead stay running in the foreground, but then
+ there's the question of how you know the service is "ready" before moving
+ on to starting other services that depend on it
+ <vorlon> systemd's answer to this is socket-based activation, which we
+ don't really endorse for upstart for a variety of reasons
+ <teythoon> hm, okay
+ <teythoon> so upstart does this only if expect daemon is declared in the
+ service description?
+ <vorlon> (in part because I've seen security issues when playing with the
+ systemd implementation on Fedora, which Lennart assures me are
+ corner-cases specific to cups, but I haven't had a chance to test yet
+ whether he's right)
+ <teythoon> and it is not used to track children, but only to observe the
+ daemonizing process?
+ <vorlon> yes
+ <teythoon> and it then detaches from the processes?
+ <vorlon> yes
+ <vorlon> once it knows the service is "ready", upstart doesn't care about
+ tracking it; it'll receive SIGCHLD when the lead process dies, and that's
+ all it needs to know
+ <teythoon> ok, so I misunderstood the purpose of the ptracing, thanks for
+ clarifying this
+ <vorlon> my pleasure :)
+ <vorlon> I realize that doesn't really help with the problem of hurd not
+ having ptrace
+ <teythoon> no, but thanks anyway
+ <vorlon> fwiw, the alternative upstart recommends for detecting service
+ readiness is for the process to raise SIGSTOP when it's ready
+ <vorlon> doesn't require ptracing, doesn't require socket-based activation
+ definitions; does require the service to run in a different mode than
+ usual where it will raise the signal at the correct time
+ <teythoon> right, but that requires patching it, same as the socket
+ activation stuff of systemd
+ <vorlon> (this is upstart's 'expect stop')
+ <vorlon> yes
+ <vorlon> though at DebConf, there were some evil ideas floating around
+ about doing this with an LD_PRELOAD or similar ;)
+ <vorlon> (overriding 'daemonize')
+ <vorlon> er, 'daemon()'
+ <teythoon> ^^
+ <vorlon> and hey, what's suspicious about my /nick? vorlons are always
+ trustworthy
+ <vorlon> ;)
+ <teythoon> sure they are
+ <teythoon> but could this functionality be reasonably #ifdef'ed out for a
+ proof of concept port?
+ <vorlon> hmm, you would need to implement some kind of replacement... if
+ you added cgroups support to upstart as an alternative
+ <vorlon> that could work
+ <vorlon> i.e., you would need upstart to know when the service has exited;
+ if you aren't using ptrace, you don't know the "lead pid" to watch for,
+ so you need some other mechanism --> cgroups
+ <vorlon> and even then, what do you do for a service like openssh, which
+ explicitly wants to leave child processes behind when it restarts?
+ <teythoon> right...
+ <vorlon> oh, I was hoping you knew the answer to this question ;) Since
+ AFAICS, openssh has no native support for cgroups
+ <teythoon> >,< I don't, but I'll think about what you've said... gotta go,
+ catch what's left of the summer ;)
+ <teythoon> fwiw I consider fork/exec/the whole daemonizing stuff fubar...
+ <teythoon> see you around :)
+ <vorlon> later :)
+## IRC, OFTC, #debian-hurd, 2013-09-07
+ <teythoon> vorlon: I thought about upstarts use of ptrace for observing the
+ daemonizing process and getting hold of the child
+ <teythoon> vorlon: what if cgroup(f)s would guarantee that the order of
+ processes listed in x/tasks is the same they were added in?
+ <teythoon> vorlon: that way, the first process in the list would be the
+ daemonized child after the original process died, no?
+ <vorlon> teythoon: that doesn't tell you how many times the "lead" process
+ has changed, however
+ <vorlon> you need synchronous notifications of the forks in order to know
+ that, which currently we only get via ptrace
+## IRC, OFTC, #debian-hurd, 2013-09-08
+ <teythoon> vorlon: ok, but why do the notifications have to be synchronous?
+ does that imply that the processes need to be stopped until upstart does
+ something?
+ <vorlon> teythoon: well, s/synchronous/reliable/
+ <vorlon> you're right that it doesn't need to be synchronous; but it can't
+ just be upstart polling the status of the cgroup
+ <vorlon> because processes may have come and gone in the meantime
+ <teythoon> vorlon: ok, cool, b/c the notifications of process changes I'm
+ hoping to introduce into the proc server for my cgroupfs do carry exactly
+ this kind of information
+ <vorlon> cool
+ <vorlon> are you discussing an API for this with the Linux cgroups
+ maintainers?
+ <teythoon> otoh it would be somewhat "interesting" to get upstart to use
+ this b/c of the way the mach message handling is usually implemented
+ <vorlon> :)
+ <teythoon> no, I meant in order for me to be able to implement cgroupfs I
+ had to create these kind of notifications, it's not an addition to the
+ cgroups api
+ <teythoon> is upstart multithreaded?
+ <vorlon> no
+ <vorlon> threads are evil ;)
+ <teythoon> ^^ I mostly agree
+ <vorlon> it uses a very nice event loop, leveraging signalfd among other
+ things
+ <teythoon> uh oh, signalfd sounds rather Linuxish
+ <pinotree> it is
+ <vorlon> I think xnox mentioned when he was investigating it that kfreebsd
+ now also supports it
+ <vorlon> but yeah, AFAIK it's not POSIX
+ <pinotree> it isn't, yes
+ <vorlon> but it darn well should be
+ <vorlon> :)
+ <vorlon> it's the best improvement to signal handling in a long time
+ <teythoon> systemd also uses signalfd
+ <teythoon> umm, it seems I was wrong about Hurd not having ptrace, the wiki
+ suggests that we do have it
+ <pinotree> FSVO "have"
+ <teythoon> ^^
+ <xnox> vorlon: teythoon: so ok kFreeBSD/FreeBSD ideally I'd be using
+ EVFILT_PROC from kevent which allows to receive events & track: exit,
+ fork, exec, track (follow across fork)
+ <xnox> upstart also uses waitid()
+ <xnox> so a ptrace/waitid should be sufficient to track processes, if Hurd
+ has them.
+## IRC, freenode, #hurd, 2013-09-09
+ <youpi> teythoon: yes, the shutdown notifications do stall the process
+ <youpi> but no more than a minute, or so
+ <youpi> teythoon: btw, did you end up understanding the odd thing in
+ fshelp_start_translator_long?
+ <youpi> I haven't had the time to have a look
+ <teythoon> youpi: what odd thing? the thing about being implemented by hand
+ instead of using the mig stub?
+ <youpi> the thing about the port being passed twice
+ <youpi> XXX this looks wrong to me, please have a look
+ <youpi> in the mach_port_request_notification call
+ <teythoon> ah, that was alright, yes
+ <youpi> ok
+ <youpi> so I can drop it from my TODO :)
+ <teythoon> this is done on the control port so that a translator is
+ notified if the "parent" translator dies
+ <teythoon> was that in fshelp_start_translator_long though? I thought that
+ was somewhere else
+ <youpi> that's what the patch file says
+ <youpi> +++ b/libfshelp/start-translator-long.c
+ <youpi> @@ -293,6 +293,7 @@ fshelp_start_translator_long (fshelp_open_fn_t
+ underlying_open_fn,
+ <youpi> + /* XXX this looks wrong to me, bootstrap is used twice as
+ argument... */
+ <youpi> bootstrap,
+ <teythoon> right
+ <teythoon> I remember that when I got a better grip of the idea of
+ notifications I figured that this was indeed okay
+ <teythoon> I'll have a quick look though
+ <youpi> ok
+ <teythoon> ah, I remember, this notifies the parent translator if the child
+ dies, right
+ <teythoon> and it is a NO_SENDERS notification, so it is perfectly valid to
+ use the same port twice, as we only hold a receive right
+## IRC, freenode, #hurd, 2013-09-10
+ <teythoon> braunr: are pthreads mapped 1:1 to mach threads?
+ <braunr> teythoon: yes
+ <teythoon> I'm reading the Linux cgroups "documentation" and it talks about
+ tasks (Linux threads) and thread group IDs (Linux processes) and I'm
+ wondering how to map this accurately onto Hurd concepts...
+ <teythoon> apparently on Linux there are PIDs/TIDs that can be used more or
+ less interchangeably from userspace applications
+ <teythoon> the Linux kernel however knows only PIDs, and each thread has
+ its own, and those threads belonging to the same (userspace) PID have the
+ same thread group id
+ <teythoon> aiui on Mach threads belong to a Mach task, and there is no
+ global unique identifier exposed for threads, right?
+ <teythoon> braunr: ^
+ <tschwinge> teythoon: There is its thread port, which in combination with
+ its task port should make it unique? (I might be missing context.)
+ <tschwinge> Eh, no. The task port's name will only locally be unique.
+ * tschwinge confused himself.
+ <teythoon> tschwinge, braunr: well, the proc server could of course create
+ TIDs for threads the same way it creates PIDs for tasks, but that should
+ probably wait until this is really needed
+ <teythoon> for the most part, the tasks and cgroup.procs files contain the
+ same information on Linux, and not differentiating between the two just
+ means that cgroupfs is not able to put threads into cgroups, just
+ processes
+ <teythoon> that might be enough for now
+## IRC, freenode, #hurd, 2013-09-11
+ <teythoon> ugh, some of the half-backed Linux interfaces will be a real
+ pain in the ass to support
+ <teythoon> they do stuff like write(2)ing file descriptors encoded as
+ decimal numbers for notifications :-/
+ <braunr> teythoon: for cgroup ?
+ <teythoon> braunr: yes, they have this eventfd based notification mechanism
+ <teythoon> braunr: but I fear that this is a more general problem
+ <braunr> do we need eventfd ?
+ <teythoon> I mean passing FDs around is okay, we can do this just fine with
+ ports too, but encoding numbers as an ascii string and passing that
+ around is just not a nice interface
+ <braunr> so what ?
+ <teythoon> it's not a designed interface, it's one people came up with b/c
+ it was easy to implement
+ <braunr> if it's meant for compatibility, that's ok
+ <teythoon> how would you implement this then? as a special case in the
+ write(2) implementation in the libc? that sounds horrible but I do hardly
+ see another way
+ <teythoon> ok, some more context: the cgroup documentation says
+ <teythoon> write "<event_fd> <control_fd> <args>" to cgroup.event_control.
+ <teythoon> where event_fd is the eventfd the notification should be sent to
+ <pinotree> theorically they could have used sendmsg + a custom payload
+ <teythoon> control_fd is an fd to the pseudo file one wants notifications
+ for
+ <teythoon> yes, they could have, that would have been nicer to implement
+ <teythoon> but this...
+## IRC, freenode, #hurd, 2013-09-12
+ <teythoon> ugh, gnumachs build system drives me crazy %-/
+ <pinotree> oh there's worse than that
+ <teythoon> I added a new .defs file, did as told me to do,
+ but it still does not create the stubs I need
+ <braunr> teythoon: gnumach doesn't
+ <braunr> teythoon: glibc does
+ <braunr> well, gnumach only creates the stubs it needs
+ <braunr> teythoon: you should perhaps simply use gnumach.defs
+ <teythoon> braunr: sure it does, e.g. vm/memory_object_default.user.c
+ <braunr> teythoon: what are you trying to add ?
+ <teythoon> braunr: I was trying to add a notification mechanism for new
+ tasks
+ <teythoon> b/c now the proc server has to query all task ports to discover
+ newly created tasks, this seems wasteful
+ <teythoon> also if the proc server could be notified on task creation, the
+ parent task is still around, so the notification can carry a reference to
+ it
+ <teythoon> that way gnumach wouldn't have to track the relationship, which
+ would create all kind of interesting questions, like whether tasks would
+ have to be reparented if the parent dies
+ <braunr> teythoon: notifications aren't that simple either
+ <teythoon> y not?
+ <braunr> 1/ who is permitted to receive them
+ <braunr> 2/ should we contain them to hurd systems ? (e.g. should a subhurd
+ receive notifications concerning tasks in other hurd systems ?)
+ <teythoon> that's easy imho. 1/ a single process that has a host_priv
+ handle is able to register for the notifications once
+ <braunr> what are the requirements so cgroups work as expected concerning
+ tasks ?
+ <braunr> teythoon: a single ?
+ <teythoon> i.e. the first proc server that starts
+ <braunr> then how will subhurd proc servers work ?
+ <teythoon> 2/ subhurds get the notifications from the first proc server,
+ and only those that are "for them"
+ <braunr> ok
+ <braunr> i tend to agree
+ <braunr> this removes the ability to debug the main hurd from a subhurd
+ <teythoon> this way the subhurds proc server doesn't even have to have the
+ host_priv porsts
+ <teythoon> yes, but I see that as a feature tbh
+ <braunr> me too
+ <braunr> and we can still debug the subhurd from the main
+ <teythoon> it still works the other way around, so it's still...
+ <teythoon> yes
+ <braunr> what would you include in the notification ?
+ <teythoon> a reference to the new task (proc needs that anyway) adn one to
+ the parent task (so proc knows what the parent process is and/or for
+ which subhurd it is)
+ <braunr> ok
+ <braunr> 17:21 < braunr> what are the requirements so cgroups work as
+ expected concerning tasks ?
+ <braunr> IOW, why is the parental relation needed ?
+ <braunr> (i don't know much about the details of cgroup)
+ <teythoon> well, currently we rely on proc_child to build this relation
+ <teythoon> but any task can use task_create w/o proc_child
+ <teythoon> until one claims a newly created task with proc_child, its
+ parent is pid 1
+ <braunr> that's about the hurd
+ <braunr> i'm rather asking about cgroups
+ <teythoon> ah
+ <teythoon> the child process has to end up in the same cgroup as the parent
+ <braunr> does a cgroup include its own pid namespace ?
+ <teythoon> not quite sure what you mean, but I'd say no
+ <teythoon> do you mean pid namespace as in the Linux sense of that phrase?
+ <teythoon> cgroups group processes(threads) into groups
+ <teythoon> on Linux, you can then attach controllers to that, so that
+ e.g. scheduling decisions or resource restrictions can be applied to
+ groups
+ <teythoon> braunr:
+ <braunr> teythoon: ok so a cgroup is merely a group of processes supervised
+ by a controller
+ <braunr> for resource accounting/scheudling
+ <braunr> teythoon: where does dev_pager.c do the same ?
+ <teythoon> braunr: yes. w/o such controllers cgroups can still be used for
+ subprocess tracking
+ <teythoon> braunr: well, dev_pager.c uses mig generated stubs from
+ memory_object_reply.defs
+ <braunr> ah memory_object_reply ok
+ <braunr> teythoon: have you tried adding it to EXTRA_DIST ?
+ <braunr> although i don't expect it will change much
+ <braunr> teythoon: hum, you're not actually creating client stubs
+ <braunr> create a kern/task_notify.cli file
+ <braunr> as it's done with device/memory_object_reply.cli
+ <braunr> see #define KERNEL_USER 1
+ <teythoon> braunr: right, thanks :)
+## IRC, freenode, #hurd, 2013-09-13
+ <teythoon> hm, my notification system for newly created tasks kinda works
+ <teythoon> as in I get notified when a new task is created
+ <teythoon> but the ports for the new task and the parent that are carried
+ in the notification are both MACH_PORT_DEAD
+ <teythoon> do I have to add a reference manually before sending it?
+ <teythoon> that would make sense, the mig magic transformation function for
+ task_t consumes a reference iirc
+ <braunr> ah yes
+ <braunr> that reference counting stuff is some hell
+ <teythoon> braunr: ah, there's more though, the mig transformations are
+ only done in the server stub, not in the client, so I still have to
+ convert_task_to_port myself afaics
+ <teythoon> awesome, it works :)
+ <braunr> :)
+ <teythoon> ugh, the proc_child stuff is embedded deep into libc and signal
+ handling stuff...
+ <teythoon> "improving" the child_proc stuff with my shiny new notifications
+ wrecks havoc on the system
# Required Interfaces
In the thread starting
diff --git a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
index cf41550d..7159551d 100644
--- a/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.mdwn
+++ b/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.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
@@ -16,26 +16,37 @@ License|/fdl]]."]]"""]]
IRC, unknown channel, unknown date:
- <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55: hurd_thread_cancel: Assertion '! __spin_lock_locked (&ss->critical_section_lock)' failed
+ <youpi> azeem, marcus: ext2fs.static: thread-cancel.c:55:
+ hurd_thread_cancel: Assertion '! __spin_lock_locked
+ (&ss->critical_section_lock)' failed
<youpi> I actually don't understand this assertion
<youpi> it's just before __spin_lock (&ss->critical_section_lock);
<youpi> why should one check that a lock is free before taking it ?
<youpi> just the same in hurdexec.c
- <youpi> (no, ss is not our own sigstate, so it's not safe to assume no other path can take it)
+ <youpi> (no, ss is not our own sigstate, so it's not safe to assume no
+ other path can take it)
<youpi> there's another one in sysdeps/mach/hurd/spawni.c
<youpi> and jmp-unwind.c
- <antrik> youpi: why do you think it's nonsense?... the fact that we take the lock (so we can't be interrupted) doesn't mean we are willing to wait for others to release the lock... maybe the code path should never be reached while others have a lock, or something
+ <antrik> youpi: why do you think it's nonsense?... the fact that we take
+ the lock (so we can't be interrupted) doesn't mean we are willing to wait
+ for others to release the lock... maybe the code path should never be
+ reached while others have a lock, or something
<youpi> then it's useless to take the lock
- <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_ lock here, it's the lock of the thread we want to cancel
- <antrik> what exactly is cancelling a thread?... (sorry, I don't really have experience with thread programming)
+ <youpi> "we take the lock (so we can't be interrupted)": no, it's not _our_
+ lock here, it's the lock of the thread we want to cancel
+ <antrik> what exactly is cancelling a thread?... (sorry, I don't really
+ have experience with thread programming)
<youpi> ~= killing it
- <antrik> well, we take the lock so nobody can mess with the thread while we are cancelling it, no?...
+ <antrik> well, we take the lock so nobody can mess with the thread while we
+ are cancelling it, no?...
<youpi> yes
<youpi> that is fine
- <youpi> but checking that the lock is free before taking it doesn't make sense
+ <youpi> but checking that the lock is free before taking it doesn't make
+ sense
<youpi> why nobody should be able to take the lock ?
- <youpi> and if nobody is, why do we take it ? (since nobody would be able to take it)
- <antrik> well, maybe after taking the lock, we do some action that might result in others trying to take it...
+ <youpi> and if nobody is, why do we take it ? (since nobody would be able
+ to take it)
+ <antrik> well, maybe after taking the lock, we do some action that might
+ result in others trying to take it...
<youpi> nope: look at the code :)
<youpi> or maybe the cancel_hook, but I really doubt it
diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn
index becb88b0..367db872 100644
--- a/open_issues/time.mdwn
+++ b/open_issues/time.mdwn
@@ -11,6 +11,11 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_porting]]
+# `time`
Neither the `time` executable from the GNU time package work completely
correctly, nor does the GNU Bash built-in one.
@@ -56,20 +61,20 @@ As above; also here all the running time should be attributed to *user* time.
This is probably a [[!taglink open_issue_gnumach]].
-# 2011-09-02
+## 2011-09-02
Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account
-- I believe flubber has already been Xenified at that time.
-## IRC, freenode, #hurd, 2011-09-02
+### IRC, freenode, #hurd, 2011-09-02
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).
-# 2013-03-30/31
+## 2013-03-30/31
Investigating time's `configure`, a difference of the output between Linux and
Hurd shows:
@@ -81,3 +86,754 @@ This causes a different code path in `resuse.c` to be used; such code path does
not get a define for `HZ`, which is then defined with a fallback value of 60.
[[!debbug 704283]] has been filed with a fix for this no-wait3 case.
+# `times`
+## guile
+### IRC, freenode, #hurd, 2013-08-21
+ <nalaginrut> does guile2 on hurd fixed? times issue
+ <teythoon> nalaginrut: does not look good
+ <teythoon> scheme@(guile-user)> (times)
+ <teythoon> $1 = #(0 0 0 0 0)
+ <nalaginrut> well, seems not a fixed version, if there's fixed version
+ <nalaginrut> since it's not Guile's bug, I can do nothing for it
+ <teythoon> ah
+ <nalaginrut> in spite of this, Guile2 works I think
+ <nalaginrut> all tests passed but 2 fail
+ <nalaginrut> one of the failure is version shows "UNKNOWN" which is
+ trivials
+ <teythoon> well, did you try to fix the times issue in Hurd?
+ <nalaginrut> I didn't , I have to get more familiar with hurd first
+ <nalaginrut> I'm playing hurd these days
+ <teythoon> :)
+ <nalaginrut> anyway, I think times issue is beyond my ability at present
+ <nalaginrut> ;-P
+ <teythoon> times is implemented in the glibc, in sysdeps/mach/hurd/times.c
+ <teythoon> don't say that before you had a look
+ <nalaginrut> yes, you're right
+ <nalaginrut> but I think times has something to do with the kernel time
+ mechanism, dunno if it's related to the issue
+ <nalaginrut> how did you get the times.c under hurd?
+ <nalaginrut> apt-get source glibc?
+ <teythoon> well, I'd clone git://
+ <teythoon> and yes, the kernel is involved
+ <teythoon> task_info is used to obtain the actual values
+ <teythoon>
+ <teythoon> I'd guess that something fails, but the times(2) interface is
+ not able to communicate the exact failure
+ <nalaginrut> maybe it's not proper to get src from upstream git? since it's
+ OK under Linux which uses it too
+ <nalaginrut> but apt-get source glibc has nothing
+ <teythoon> so I would copy the times(2) implementation from the libc so
+ that you can modify it and run it as a standalone program
+ <teythoon> well, the libc has system dependent stuff, times(2) on Linux is
+ different from the Hurd version
+ <teythoon> it has to be
+ <nalaginrut> alright, I got what you mean ;-)
+ <teythoon> and the debian libc is built from the eglibc sources, so the
+ source package is called eglibc iirc
+ <nalaginrut> ah~I'll try
+ <teythoon> have you tried to rpctrace your times test program? the small c
+ snippet you posted the other day?
+ <nalaginrut> I haven't build all the tools & debug environment on my hurd
+ ;-(
+ <teythoon> what tools?
+ <nalaginrut> well, I don't even have git on it, and I'm installing but
+ speed is slow, I'm looking for a new mirror
+ <teythoon> ah well, no need to do all this on the Hurd directly
+ <teythoon> building the libc takes like ages anyway
+ <nalaginrut> oops ;-)
+ <nalaginrut> I'll take your advice to concentrate on times.c only
+ <teythoon> oh well, it might be difficult after all, not sure though
+ <teythoon> times sends two task_info messages, once with TASK_BASIC_INFO,
+ <teythoon> here is the relevant rpctrace of your test program:
+ <teythoon> task131(pid14726)->task_info (1 10) = 0 {0 25 153427968 643072 0
+ 0 0 0 1377065590 570000}
+ <teythoon> task131(pid14726)->task_info (3 4) = 0 {0 0 0 10000}
+ <teythoon> ok, I don't know enough about that to be honest, but
+ TASK_THREAD_TIMES_INFO behaves funny
+ <teythoon> I put a sleep(1) into your test program, and if I rpctrace it,
+ it behaves differently o_O
+ * nalaginrut is reading task-information page to get what it could be
+ <nalaginrut> maybe I have to do the same steps under Linux to find some
+ clue
+ <teythoon> no, this is Mach specific, there is no such thing on Linux
+ <teythoon> on Linux, times(2) is a system call
+ <teythoon> on Hurd, times is a function implemented in the libc that
+ behaves roughly the same way
+ <nalaginrut> OK~so different
+ <teythoon> look at struct task_basic_info and struct task_thread_times_info
+ in the task-information page for the meaning of the values in the
+ rpctrace
+ <teythoon> yes, very
+ <braunr> nalaginrut: you may want to try a patch i did but which is still
+ waiting to be merged in glibc
+ <nalaginrut> braunr: ah~thanks for did it ;-)
+ <nalaginrut> can I have the link?
+ <braunr> i'm getting it
+ <braunr> teythoon: funny things happen with rpctrace, that's expected
+ <braunr> keep in mind rpctrace doesn't behave like ptrace at all
+ <braunr> it acts as a proxy
+ <braunr> nalaginrut:
+ <braunr> nalaginrut: you need to add it to the debian eglibc patch list,
+ rebuild the packages, and install the resulting .debs
+ <braunr> if you have trouble doing it, i'll make packages when i have time
+ <nalaginrut> braunr: I think your test result is expected? ;-)
+ <braunr> what test result ?
+ <nalaginrut> times test under that patch
+ <braunr> yes
+ <braunr> but i have no idea if it will work
+ <braunr> my patch fixes a mismatch between glibc and the procfs server
+ <braunr> nothing more
+ <braunr> it may help, it may not, that's what i'd like to know
+ <nalaginrut> hah~thanks for that
+ <nalaginrut> I get source from apt-get, then manually modified the files,
+ no much code ;-)
+ <nalaginrut> compiling
+ <nalaginrut> there is no cpuinfo in /proc?
+ <teythoon> no
+ <nalaginrut> a feature need to be done? or there's another way for that?
+ <teythoon> well, it hasn't been implemented
+ <teythoon> do you need that? what for?
+ <nalaginrut> compiling error, I realized I should use gcc-4.7
+ <pinotree> how are you building?
+ <nalaginrut> I just happened to play proc while compiling, and found
+ there's no
+ <nalaginrut> cxa_finalize.c:48:1: error: ‘tcbhead_t’ has no member
+ named ‘multiple_threads’
+ <nalaginrut> I changed to gcc-4.7
+ <pinotree> just edit the sources, and then dpkg-buildpackage -nc -us -uc
+ <pinotree> that will rebuild the debian package as it would be in a debian
+ build, making sure all the build dependencies are there, etc
+ <pinotree> doing it different than that is just wrong™
+ <nalaginrut> ok, doing
+ <pinotree> were you really doing ./configure etc yourself?
+ <nalaginrut> well, I can't wait till it's done, I'll let it compile and
+ check it out tomorrow
+ <nalaginrut> I used configure, yes ;-P
+ <pinotree> not good
+ <nalaginrut> I have to go, thanks for help guys
+### IRC, freenode, #hurd, 2013-08-22
+ < nalaginrut> eglibc was done by dpkg-buildpackage, then how to install it?
+ (sorry I'm a brand new debian users)
+ < nalaginrut> oh~I found it
+ < nalaginrut> yes, (times) returns reasonable result ;-)
+ * nalaginrut is trying 'make check'
+ < nalaginrut> unfortunately, it can't pass the test though, I'm researching
+ it, anyway, we made first step
+ < nalaginrut> for Hurd internal-time-units-per-second will be 1000
+ < nalaginrut> , but the elapsed time is far larger than (* 2
+ internal-time-units-per-second)
+ < nalaginrut> I think the different of two returned clocks after 1 second
+ should be the TIME_UNITS_PER_SECOND, in principle
+ < nalaginrut> but I'm not sure if it's elibc or Guile bug
+ < nalaginrut> dunno, maybe clock tick should be 1000?
+ < nalaginrut> well, I'll try clock per second as 1000
+ < braunr> nalaginrut: clock tick (or actually, the obsolete notion of a
+ clock tick in userspace) should be 100
+ < braunr> nalaginrut: how did you come with 1000 ?
+ < nalaginrut> braunr: Guile set TIME_UNITS_PER_SECOND to 1000 when there's
+ no 8bytes size and doesn't define HAVE_CLOCK_GETTIME
+ < nalaginrut> #if SCM_SIZEOF_LONG >= 8 && defined HAVE_CLOCK_GETTIME
+ < nalaginrut> #define TIME_UNITS_PER_SECOND 1000000000
+ < nalaginrut> #else
+ < nalaginrut> #define TIME_UNITS_PER_SECOND 1000
+ < nalaginrut> #endif
+ < nalaginrut> and the test for 'times' used time-units-per-second
+ < pinotree> what has sizeof(long) have to do with time units per second?
+ < nalaginrut> dunno, maybe the representation of time?
+ < nalaginrut> the test failed since the difference between two clocks after
+ 1sec is too large
+ < nalaginrut> and for the test context, it should small than 2 times of
+ units-per-second
+ < nalaginrut> should be smaller
+ < nalaginrut> sorry for bad English
+ < pinotree> aren't you basically looking for clock_getres?
+ < nalaginrut> pinotree: I don't understand what you mean
+ < pinotree>
+ < nalaginrut> I wonder if there's a standard CLK_PER_SEC for Hurd
+ < nalaginrut> or it can be modified as wish
+ < pinotree> why do you need it?
+ < nalaginrut> the difference is 10,000,000, which can never less than
+ 2*clock_per_second
+ < nalaginrut> pinotree: I don't need it, but I want to know if there's a
+ standard value
+ < braunr> nalaginrut: ok so, this is entirely a guile thing
+ < braunr> nalaginrut: did you test with my patch ?
+ < nalaginrut> braunr: yes, 'times' works fine
+ < braunr> but even with that, a tets fails ?
+ < braunr> test*
+ < nalaginrut> well, I can't say works fine, the proper description is "now
+ it has reasonable result"
+ < braunr> youpi: could you bring
+ into debian glibc btw ?
+ < nalaginrut> braunr: it failed the test since the clock run too fast, but
+ it should be smaller than 2*clk-per-sec
+ < braunr> i don't get that
+ < braunr> can you show the code that checks the condition ?
+ < nalaginrut> braunr:
+ < braunr> * 0.5 internal-time-units-per-second ?
+ < nalaginrut> for C users, it's just like
+ a=times(...);sleep(1);b=times(...); then time-units-per-sec/2 <= (b-a) <=
+ time-units-per-sec*2
+ < braunr> ah ok
+ < nalaginrut> the test passes when it's true
+ < braunr> so basically, it says sleep(1) sleeps for more than 2 seconds
+ < braunr> can you check the actual value ?
+ < braunr> b-a
+ < nalaginrut> hold on for minutes
+ < nalaginrut> it's 10,000,000
+ < nalaginrut> for clk-per-sec=1000,000,000, it's OK
+ < nalaginrut> but for 100 or 1000, it's too small
+ < braunr> let's forget 100
+ < braunr> guile uses 1000
+ < nalaginrut> OK
+ < braunr> but i still don't get why
+ < nalaginrut> so I asked if there's standard value, or it can be ajustified
+ < nalaginrut> adjusted
+ < braunr> ok so, times are expressed in clock ticks
+ < braunr> are you sure you're using a patched glibc ?
+ < nalaginrut> yes I used your patch, and the 'times' get reasonable result
+ < braunr> then
+ < braunr> 11:28 < nalaginrut> it's 10,000,000
+ < braunr> doesn't make sense
+ < nalaginrut> hmm
+ < braunr> anhd i don't understand the test
+ < braunr> what's tms:clock new ?
+ < nalaginrut> it's actually the return value of 'times'
+ < nalaginrut> Guile wrap the clock_t and tms to a vector, then we can get
+ all the thing in a row
+ < nalaginrut> 'new' is a variable which was gotten after 1 sec
+ < braunr> let's see what this does exactly
+ < nalaginrut> equal to "new = times(...)"
+ < nalaginrut> 'tms' equal to (clock_t (struct tms))
+ < nalaginrut> we have to pass in the struct pointer to get the struct
+ values filled, but for Guile we don't use pointer, times actually returns
+ two things: clock_t and struct tms
+ < nalaginrut> and Guile returns them as a vector in a row, that's it
+ < braunr> nalaginrut: test this please:
+ < braunr> i don't have a patched libc here
+ < braunr> i'll build one right now
+ < nalaginrut> clock ticks: 1000000
+ < braunr> and this seems reasonable to you ?
+ < braunr> anyway, i think the guile test is bugged
+ < nalaginrut> no, the reasonable is not for this
+ < braunr> does it ever get the clock tick value from sysconf() ?
+ < nalaginrut> I say reasonable since it's always 0 both for clock and tms,
+ before apply your patch
+ < braunr> uh no
+ < braunr> i have the same value, without my patch
+ < nalaginrut> so I said "I can't say it works fine"
+ < braunr> either the test is wrong because it doesn't use sysconf()
+ < nalaginrut> anyway, I don't think times should return "all zero"
+ < braunr> or the clock values have already been ocnverted
+ < braunr> but it doesn't
+ < braunr> you did something wrong
+ < nalaginrut> with your patch it doesn't
+ < braunr> without neither
+ < braunr> 11:43 < braunr> i have the same value, without my patch
+ < nalaginrut> well, it's too strange
+ < braunr> check how the test actually gets the clock values
+ < braunr> also, are your running in vbox ?
+ < braunr> you*
+ < nalaginrut> no ,it's physical machine
+ < braunr> oh
+ < braunr> nice
+ < braunr> note that vbox has timing issues
+ < nalaginrut> I thought I should give you some info of CPU, but there's no
+ /proc/cpuinfo
+ < braunr> shouldn't be needed
+ < nalaginrut> OK
+ < braunr> run my test again with an unpatched glibc
+ < braunr> just to make sure it produces the same result
+ < braunr> and
+ < nalaginrut> so the clock-per-sec is machine independent for Hurd I think
+ < braunr> 11:46 < braunr> check how the test actually gets the clock values
+ < nalaginrut> since it's implemented in userland
+ < braunr> clock-per-sec is always system dependent
+ < braunr> All times reported are in clock ticks.
+ < braunr> The number of clock ticks per second can be obtained
+ using:
+ < braunr> sysconf(_SC_CLK_TCK);
+ < braunr> 11:46 < braunr> check how the test actually gets the clock values
+ < braunr> to see if they're converted before reaching the test code or not
+ * nalaginrut is building eglibc
+ < braunr> building ?
+ < braunr> what for ?
+ < nalaginrut> I modified it to 1000, now it's useless
+ < braunr> we want it to 100 either way
+ < nalaginrut> and how to reinstall eglibc under debian?
+ < braunr> it's obsolete, procfs already uses 100, and 100 is low enough to
+ avoid overflows in practically all cases
+ < braunr> aptitude install libc0.3=<version>
+ < nalaginrut> OK
+ < braunr> aptitude show -v libc0.3
+ < braunr> for the list of available versions
+ < nalaginrut> out of topic, what's the meaning of the code in
+ quantize_timeval ?
+ < nalaginrut> tv->tv_usec = ((tv->tv_usec + (quantum - 1)) / quantum) *
+ quantum;
+ < nalaginrut> I can't understand this line
+ < braunr> scaling and rounding i guess
+ < nalaginrut> hmm...but quantum seems always set to 1?
+ < nalaginrut> 100/__getclktck()
+ < braunr> ah right
+ < braunr> old crap from the past
+ < nalaginrut> and clk-tck is 100
+ < braunr> the author probably anticipated clk_ticks could vary
+ < braunr> in practice it doesn't, and that's why it's been made obsolete
+ < nalaginrut> I wonder if it could be vary
+ < braunr> no
+ < nalaginrut> alright
+ < nalaginrut> why not just assign it to 1?
+ < braunr> 11:55 < braunr> old crap from the past
+ < braunr> the hurd is 20 years old
+ < braunr> like linux
+ < nalaginrut> oh~
+ < braunr> but with a lot less maintenance
+ < nalaginrut> braunr: well, I tried the original eglibc, your test was
+ clock ticks: 1000000
+ < nalaginrut> but in Guile, (times) ==> (0 0 0 0 0)
+ < nalaginrut> the reasonable result maybe: #(4491527510000000 80000000 0 0
+ 0)
+ < braunr> 11:46 < braunr> check how the test actually gets the clock values
+ < braunr> ah, he left
+### IRC, freenode, #hurd, 2013-08-23
+ < braunr> nalaginrut: times() doesn't seem to be affected by my patch at
+ all
+ < nalaginrut> braunr: but it did in my machine
+ < nalaginrut> well, I think you mean it doesn't affect your C test code
+ < braunr> i'm almost sure something was wrong in your test
+ < braunr> keep using the official debian glibc package
+ < nalaginrut> I don't think it's test issue, since every time (times)
+ return zero, the test can never get correct result
+ < braunr> times doesn't return 0
+ < braunr> for sleep(1), i always have the right result, except in
+ microseconds
+ < nalaginrut> times in Guile always return #(0 0 0 0 0)
+ < braunr> (microseconds is the native mach time unit)
+ < braunr> well, guile does something wrong
+ < nalaginrut> after sleep 1, it's 0 again, so it's none sense
+ < braunr> 11:46 < braunr> check how the test actually gets the clock values
+ < braunr> not on my system
+ < nalaginrut> but (times) returns reasonable result after applied your
+ patch
+ < braunr> that's not normal, since times isn't affected by my patch
+ < nalaginrut> oops
+ < braunr> you need to look for what happens in guile between the times()
+ call and the #(0 0 0 0 0) values
+ < nalaginrut> well, I tried many times between patch or non-patch, I think
+ there's no mistake
+ < nalaginrut> I read the 'times' code in Guile, there's nothing strange,
+ just call 'times' and put all the result to a vector
+ < braunr> which means there is no conversion
+ < braunr> in which case the test is plain wrong since there MUST also be a
+ call to sysconf()
+ < braunr> to obtain the right clock ticks value
+ < braunr> is your box reachable with ssh ?
+ < nalaginrut> oh~wait, seems there's a quotient operation, I'm checking
+ < nalaginrut> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
+ < nalaginrut> scm_from_long (ticks_per_second));
+ < braunr> iirc, TIME_UNITS_PER_SECOND is hardcoded
+ < nalaginrut> unless factor is zero
+ < nalaginrut> yes, it's hardcoded
+ < braunr> that's completely non portable and wrong
+ < nalaginrut> you suggest to call sysconf?
+ < braunr> yes
+ < braunr> but i don't have the code in mind
+ < braunr> what is ticks_per_second ?
+ < nalaginrut> OK, that's one issue, we have to find why times return 0
+ < braunr> 14:14 < braunr> is your box reachable with ssh ?
+ < braunr> i'd like to make sure times returns 0 at your side
+ < braunr> because it doesn't at mine
+ < nalaginrut> no
+ < braunr> until i can reproduce, i can't consider there is a problem
+ < nalaginrut> I think it's unreachable for outer space
+ < nalaginrut> well, if you want to reproduce, just get guile src of debian
+ < braunr> guile 2.0 ?
+ < nalaginrut> yes, apt-get source guile-2.0
+ < nalaginrut> I'm checking ticks_per_second
+ < braunr> got the source, how do i test
+ < braunr> ?
+ < nalaginrut> you have to build it, and run ./meta/guile, then you don't
+ have to install it
+ < nalaginrut> and try (times)
+ < braunr> aw libgc
+ < nalaginrut> the reasonable result should be #(4313401920000000 110000000
+ 20000000 0 0) or something alike
+ < nalaginrut> but #(0 0 0 0 0) in each time is not reasonable apparently
+ < nalaginrut> maybe you need apt-get build-dep guile-2.0?
+ < braunr> already done
+ < nalaginrut> building Guile2 may take very long time
+ < nalaginrut> about 30 minutes in my old machine
+ < braunr> then it should take just a few minutes on mine
+ < nalaginrut> alright it's not very long, I've spent 8 hours for gcc in LFS
+ < braunr> 8 hours ?
+ < braunr> takes 5-10 minutes on a common machine ..
+ < nalaginrut> but it's Celeron566 at that time...
+ < braunr> ah, that old
+ < nalaginrut> include bootstrap, so very long
+ < braunr> nalaginrut: i got the test failure from the build procedure, how
+ do i run it manually ?
+ < nalaginrut> braunr: ./meta/guile -L test-suite
+ test-suite/tests/time.test
+ < nalaginrut> braunr: or make check for all
+ < braunr> put a print after the schedule() and before the return nil; in
+ runtime_mstart, since that's the body of new threads
+ < nlightnfotis> unfortunately, I can't confirm this with goroutines
+ running; the assertion failure aborts before I can get anything useful
+ < braunr> you can
+ < braunr> make sure there is a \n in the message, since stdout is line
+ buffered by default
+ < braunr> if you don't reach that code, it means threads don't exit
+ < braunr> at least goroutine threads
+ < braunr> btw, where is the main thread running ?
+ < nlightnfotis> I just checked there is a \n at the end.
+ < nlightnfotis> "<braunr> btw, where is the main thread running " could you
+ elaborate a little bit on this?
+ < braunr> what does main() after initializing the runtime ?
+ < braunr> +do
+ < nlightnfotis> the runtime main or the process's main?
+ < braunr> the process
+ < braunr> nlightnfotis: what we're interested in is knowing whether main()
+ exits or not
+ < nlightnfotis> braunr: I can see there are about 4 functions of interest:
+ runtime_main (the main goroutine, and I can imagine 1st thread)
+ < nlightnfotis> main_init (I don't know what it does, will check this out
+ now)
+ < nlightnfotis> main_main (not sure about this one either)
+ < nlightnfotis> and runtime_exit (0)
+ < braunr> i can see that too
+ < braunr> i'm asking about main()
+ < nlightnfotis> which seems to be the function that terminates the main
+ thread
+ < nlightnfotis> <braunr> nlightnfotis: what we're interested in is knowing
+ whether main() exits or not --> my theory is runtime_exit (0) exits the
+ process' main. Seeing as at various times go programs echo $? == 0.
+ < nlightnfotis> let me research that a little bit
+ < nlightnfotis> braunr: that will require a bit more studying. main_main()
+ and main_init() are both expanded to assembly tags if I understand it
+ correctly.
+ < nlightnfotis> main.main and __go_init_main respectively.
+ < braunr> why are you looking from there instead of looking from main() ?
+ < nlightnfotis> are we not looking out if main exits?
+ < braunr> we are
+ < braunr> so why look at main_main ?
+ < braunr> or anything else than main ?
+ < nlightnfotis> these are called inside runtime_main and I figured out they
+ might have a clue
+ < braunr> runtime_main != main
+ < braunr> (except if there is aliasing)
+ < nlightnfotis> there is still the possibility that runtime_main is the
+ main function and that runtime_exit(0) exits it.
+ < braunr> there is no doubt that main is main
+ < braunr> (almost)
+ < nlightnfotis> and I just found out that there is no main in assembly
+ produced from go. Only main.main
+ < braunr> check the elf headers for the entry point then
+ < nlightnfotis> braunr: I went through the headers, and found the process'
+ main. You can find it in <gcc_root>/libgo/runtime/go-main.c
+ < nlightnfotis> it seems very strange though: It creates a new thread, then
+ aborts?
+ < braunr> nlightnfotis: see :)
+ < braunr> nlightnfotis: add traces there
+ < nlightnfotis> braunr: can you look into that piece of code to check out
+ something I don't understand?
+ < nlightnfotis> braunr: I can not seem able to find __go_go 's definition
+ < nlightnfotis> only a declaration in runtime.h
+ < braunr>
+ line 1552
+ < nlightnfotis> gee thanx. For a strange kind of fashion, I was looking for
+ it in runtime.c
+ < braunr> use git grep
+ < braunr> or tags/cscope
+ < nlightnfotis> braunr: yep! runtime_exit does seem to terminate a go
+ process that was not otherwise abnormally terminated.
+ < braunr> ?
+ < braunr> is it called or not ?
+ < braunr> runtime_exit is a macro on exit()
+ < braunr> so we already know what it does
+ < nlightnfotis> it is called
+ < braunr> ok
+ < braunr> that's not normal :)
+ < nlightnfotis> for a simple program
+ < braunr> uh ?
+ < nlightnfotis> for one that has a go routine
+ < braunr> but
+ < nlightnfotis> it doesn't
+ < nlightnfotis> it's expected
+ < braunr> ok
+ < braunr> that makes sense
+ < braunr> well, trace
+ < braunr> keep tracing
+ < braunr> for example in main()
+ < braunr> is runtime_mstart() actually reached ?
+ < nlightnfotis> yeah main and runtime_main were my next two targets
+ < braunr> good
+ < nlightnfotis> and now I followed your advice and it does compiler much
+ faster
+ < braunr> so, it looks like the main thread just becomes a mere kernel
+ thread
+ < braunr> running runtime_mstart() and fetching goroutines as needed
+ < braunr> after your traces, i'd suggest running a small go test program,
+ with one simple goroutine (doesn't crash right ?)
+ < braunr> and trace context switching
+ < braunr> but after the traces
+ < braunr> one important trace is to understand why runtime_exit gets called
+ < nlightnfotis> it does crash even with 1 goroutine
+ < braunr> oh
+ < braunr> when doesn't it crash ?
+ < nlightnfotis> when it has 0 goroutines
+ < nlightnfotis> it works as expected
+ < nlightnfotis> but anything involving goroutines crashes
+ < nlightnfotis> and goroutines are very important; everything in the
+ standard library involves goroutines
+ < braunr> ok
+ < braunr> doesn't change what i suggested, good
+ < braunr> 1/ find out why runtime_exit gets called
+ < braunr> 2/ trace context switching with 1 goroutine
+ < nlightnfotis> on it.
+ < braunr> in all cases, make all your goroutines (including the main one)
+ *not* return
+ < braunr> so that you don't deal with goroutine destruction yet
+ < nlightnfotis> runtime_mstart in main doesn't to be run at all. So the
+ path is __go_go and then return from it.
+ < nlightnfotis> *doesn't seem
+### IRC, freenode, #hurd, 2013-08-26
+ < braunr> youpi: my glibc clock patch looks incomplete btw
+ < youpi> which one?
+ < youpi> ah, the ticks one?
+ < braunr> yes
+ < braunr> it doesn't change the values returned by times
+ < braunr> as a side effect, the load average bumps to 2+ on an idle machine
+### IRC, freenode, #hurd, 2013-08-27
+ < nalaginrut> braunr: have you tried Guile2 on your machine? ;-)
+ < braunr> nalaginrut: no
+ < braunr> nalaginrut: but i saw the code actually does use sysconf()
+ < nalaginrut> braunr: yes, for ticks_per_second
+ < braunr> i had to look myself to find it out, you didn't say it, despite
+ me asking multiple times
+ < braunr> it won't make debugging easier ;p
+ < braunr> nalaginrut: also, the return value of times is actually *never*
+ used
+ < braunr> i don't know why you've been talking about it so much
+ < nalaginrut> braunr: I'm sorry, it's first time to look stime.c for me
+ < braunr> the interesting function is get_internal_run_time_times()
+ < nalaginrut> what do you mean about "the return value of times is actually
+ *never* used"? in which context?
+ < braunr> see get_internal_run_time_times
+ < braunr> struct tms time_buffer;
+ < braunr> times(&time_buffer);
+ < braunr> return ...
+ < braunr> and yes, the user and system time reported in struct tms are 0
+ < braunr> let's see what posix has to say about it
+ < pinotree> it says it will return (clock_t)-1 for errors, but no standard
+ errors are defined yet
+ < nalaginrut> but I don't think get_internal_run_time_times has something
+ to do with scm_times
+ < braunr> well, i don't see any other call to times()
+ < braunr> i've asked you repeatedly to look for how guile fetches the data
+ < braunr> i think it's done in get_internal_run_time_times
+ < braunr> what makes you think otherwise ?
+ < braunr> our times() seems to behave fine, other than the units of the
+ return value
+ < nalaginrut> I don't understand what do you mean?
+ get_internal_run_time_times is unrelated to scm_times which is actually
+ "times" in Scheme code
+ < braunr> ok
+ < nalaginrut> I think we're talking about "times" activity, right?
+ < braunr> ok so result is a vector
+ < braunr> with the return value and the four values in struct tms
+ < nalaginrut> yes
+ < braunr> and what looks interesting is
+ < braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
+ scm_from_long (ticks_per_second));
+ < braunr> SCM_SIMPLE_VECTOR_SET (result, 0, scm_product (scm_from_long
+ (rv), factor));
+ < braunr> TIME_UNITS_PER_SECOND is 1000
+ < nalaginrut> yes, it means (clock_t *
+ (TIME_UNITS_PER_SECOND/ticks_per_second)), though I've no idea why it
+ does this
+ < braunr> normalizing values i guess
+ < nalaginrut> I wonder if the factor should be 1, just guessing
+ < braunr> let's see what our clock tick really is
+ < braunr> 1000000 on an unmodified libc
+ < braunr> 100 with my patch
+ < nalaginrut> so what's the problem?
+ < nalaginrut> all the values were multiplied by ticks, it's fair for the
+ subtraction
+ < nalaginrut> I think the problem is clock is too large for the difference
+ between utime and utime(sleep 1)
+ < nalaginrut> oops, is too small
+ < nalaginrut> sorry, I confused,
+ < nalaginrut> the problem is the difference of clock is too large for
+ 2*internal-time-units-per-second
+ < nalaginrut> and actually, internal-time-units-per-second is
+ < nalaginrut> but without your patch, 'times' would return zeros all the
+ time, which is never meet the condition: SCM_TIME_UNITS_PER_SECOND/2 <=
+ (clock2 - clock1)
+ < nalaginrut> well, maybe your point is
+ TIME_UNITS_PER_SECOND/ticks_per_second is too small without your patch,
+ which causes the scm_to_long cast give a 0 value
+ < nalaginrut> s/cast/casting
+ < nalaginrut> when ticks_per_second is 100, the factor would be 10, which
+ seems to be reasonable
+ < nalaginrut> s/scm_to_long/scm_from_long
+ < nalaginrut> well, I have to checkout this
+ < nalaginrut> OK, let me reconstruct the point: ticks_per_second so too
+ large that makes the factor becomes zero
+ < nalaginrut> but decrease ticks_per_second to 100 causes the clock become
+ too large than TIME_UNITS_PER_SECOND
+ < braunr> 10:59 < nalaginrut> but without your patch, 'times' would return
+ zeros all the time, which is never meet the condition:
+ SCM_TIME_UNITS_PER_SECOND/2 <= (clock2 - clock1)
+ < braunr> until you prove me otherwise, this is plain wrong
+ < braunr> times() never returned me 0
+ < braunr> so let's see, this gives us a factor of 1000 / 1000000
+ < braunr> so the problem is factor being 0
+ < braunr> that's why *guile* times returns 0
+ < braunr> with my patch it should return 10
+ < nalaginrut> braunr: I'm sorry I mean "stime" in Scheme returns zeros
+ < nalaginrut> yes, I think the problem is factor
+ < nalaginrut> the factor
+ < braunr> now why doesn't my patch fix it all ?
+ < braunr> ah yes, rv is still in microseconds
+ < braunr> that's what i've been telling youpi recently, my patch is
+ incomplete
+ < braunr> i'll cook a quick fix, give me a few minutes please
+ < nalaginrut> but it fixed something ;-)
+ < braunr> well, guile makes a stupid assumption here
+ < braunr> so it's not really a fix
+ < nalaginrut> braunr: should I ask some info about TIME_UNITS_PER_SECOND
+ from Guile community?
+ < nalaginrut> or it doesn't help
+ < braunr> what do you want to ask them ?
+ < nalaginrut> since I don't know how this value was chosen
+ < nalaginrut> dunno, I'll ask if you need it
+ < nalaginrut> I just think maybe you need this info
+ < braunr> well
+ < braunr> my plan is to align the hurd on what other archs do
+ < braunr> i.e. set clk_tck to 100
+ < braunr> in which case this won't be a problem any more
+ < braunr> now you could warn them about the protability issue
+ < braunr> i'm not sure if they would care though
+ < nalaginrut> the warning is useful for the future
+ < nalaginrut> and it's not hard to make a change I think, for a constant,
+ but it depends on the maintainers
+ < braunr> it's not that simple
+ < braunr> time related things can easily overflow in the future
+ < nalaginrut> alright
+ < braunr> refer to the 2038 end-of-the-world bug
+ < nalaginrut> so how can I describe the warning/suggestion to them?
+ < braunr> i'm not sure
+ < braunr> tell them the TIME_UNITS_PER_SECOND isn't appropriate for larger
+ values of clk_tck
+ < braunr> dammit, microseconds are hardcoded everywhere in
+ sysdeps/mach/hurd ... >(
+ < braunr> nalaginrut: my new patch seems to fix the problem
+ < braunr> nalaginrut: i've built debian packages with which you can
+ directly test
+ < braunr> nalaginrut: deb
+ experimental/
+ < braunr> Totals for this test run:
+ < braunr> passes: 38605
+ < braunr> failures: 0
+ < braunr> unexpected passes: 0
+ < braunr> expected failures: 7
+ < braunr> unresolved test cases: 578
+ < braunr> untested test cases: 1
+ < braunr> unsupported test cases: 10
+ < braunr> errors: 0
+ < braunr> PASS: check-guile
+ < braunr> =============
+ < braunr> 1 test passed
+ < braunr> =============
+ < braunr> :)
+ < braunr> youpi: the branch i added to glibc contains a working patch for
+ clock_t in centiseconds
+ < youpi> k
+### IRC, freenode, #hurd, 2013-08-28
+ <nalaginrut> braunr: well, looks great! I'll try it soon~
+ <nalaginrut> braunr: BTW, where is the patch/
+ <mark_weaver> braunr: what was needed to get guile working on the hurd?
+ <mark_weaver> well, if the fix wasn't to guile, I don't need the details.
+ <braunr> 04:53 < nalaginrut> braunr: BTW, where is the patch/
+ <braunr> there is hardly anyone here at 5am
+ <braunr> nalaginrut:
+ <nalaginrut> braunr: thanks for that, but why not use a constant for 100?
+ <braunr> nalaginrut: i don't know where to define it
+ <braunr> it's glibc, you don't define new stuff mindlessly
+ <youpi> braunr: about your centiseconds patch, did you run the libc
+ testsuite with it?
+ <mark_weaver> it does seem a shame to reduce the resolution of the timers
+ from microseconds to centiseconds. I wonder if that could be avoided.
+ <youpi> by fixing all applications which assume centiseconds
+ <mark_weaver> *nod* well, if there's such a problem in Guile, I'd be glad
+ to fix that.
+ <braunr> youpi: no
+ <mark_weaver> I see that there's a macro CLOCKS_PER_SEC that programs
+ should consult.
+ <youpi> braunr: ok, I'll do then
+ <braunr> mark_weaver: why is it a shame ?
+ <braunr> it's not clock or timer resolution
+ <youpi> it's clock_t resolution
+ <braunr> it's an obsolete api to measure average cpu usage
+ <braunr> having such a big value on the other hand reduces the cpu usage
+ durations
+ <mark_weaver> braunr: good point :) I confess to being mostly ignorant of
+ these APIs.
+ <mark_weaver> Though Guile should still consult CLOCKS_PER_SEC instead of
+ assuming centiseconds. If it's making an improper assumption, I'd like
+ to know so I can fix it.
+ <braunr> the improper assumption is that there are less than 1000 clock
+ ticks per second
+ <mark_weaver> do you know off-hand of some code in Guile that is making
+ improper assumptions?
+ <braunr> yes
+ <braunr> let me find it
+ <mark_weaver> thanks
+ <braunr> factor = scm_quotient (scm_from_long (TIME_UNITS_PER_SECOND),
+ <braunr> scm_from_long (ticks_per_second));
+ <braunr> it seems guile attempts to normalize all times values to
+ <braunr> while i think it would be better off using ticks_per_second (clock
+ ticks as provided by sysconf())
+ <braunr> attempting to normalize here causes factor to become 0 if
+ TIME_UNITS_PER_SECOND < ticks_per_second
+ <mark_weaver> ah, I see.
+ <mark_weaver> I'll take care of it. thanks for the pointer!
+ <youpi> braunr: I've commited the centisecond patch to debian's glibc
+### IRC, freenode, #hurd, 2013-08-29
+ <nalaginrut> braunr: Guile2 works smoothly now, let me try something cool
+ with it
+ <braunr> nalaginrut: nice
diff --git a/open_issues/tmux.mdwn b/open_issues/tmux.mdwn
new file mode 100644
index 00000000..f71d13e1
--- /dev/null
+++ b/open_issues/tmux.mdwn
@@ -0,0 +1,24 @@
+[[!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
+[[!tag open_issue_porting]]
+# IRC, freenode, #hurd, 2013-08-01
+ <braunr> teythoon: can you stop tmux on darnassus please ?
+ <braunr> i'd like to check something
+ <teythoon> done
+ <braunr> tmux makes load average grow to 5 without any visible activity :/
+ <braunr> can't reproduce it with my instances though
+ <braunr> anyway, that's minor
+ <teythoon> I used tmux before and never encountered that
+ <teythoon> sometimes tmux would hang on attaching or detaching though, but
+ overall I had less problems with tmux than with screen
+ <teythoon> ah, I tried to start tmux on darnassus and now it hangs
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index f4739776..f9dd4756 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -22,3 +22,46 @@ License|/fdl]]."]]"""]]
<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
+## IRC, freenode, #hurd, 2013-08-26
+ < teythoon> also I looked into the fakeroot issue, aiui the problem is that
+ scripts are not handled correctly, right?
+ < teythoon> the exec server fails to locate the scripts file name, and so
+ it hands the file_t to the interpreter process and passes /dev/fds/3 as
+ script name
+ < teythoon> afaics that breaks e.g. python
+ < youpi> yes
+ < youpi> pinotree's exec_file_name is supposed to fix that, but for some
+ reason it doesn't work here
+ < pinotree> it was pochu's, not mine
+ < youpi> ah, right
+ < teythoon> ah I see, I was wondering about that
+ < pochu> it was working for a long time, wasn't it?
+ < pochu> and only stopped working recently
+ < youpi> did it completely stop?
+ < youpi> I have indeed seen odd issues
+ < youpi> I haven't actually checked whether it has completely stopped
+ working
+ < youpi> probably worth looking there first
+ < pinotree> gtk+3.0 fails, but other stuff like glib2.0 and gtester-using
+ stuff works
+ < teythoon> huh? I created tests like "#!/bin/sh\necho $0" and that says
+ /dev/fd..., and a python script doing the same doesn't even run, so how
+ can it work for a package build?
+ < youpi> it works for me in plain bash
+ < youpi> #!/bin/sh
+ < youpi> echo $0
+ < youpi> € $PWD/
+ < youpi> /home/samy/
+ < teythoon> it does !?
+ < youpi> yes
+ < youpi> not in fakeroot-hurd however, as we said
+ < teythoon> well, obviously it works when not being run under
+ fakeroot-hurd, yes
+ < youpi> ok, so we weren't talking about the same thing
+ < youpi> a mere shell script doesn't work in fakeroot-hurd indeed
+ < youpi> that's why we still use fakeroot-sysv
+ < teythoon> right
+ < youpi> err, -tcp
diff --git a/open_issues/virtualization/networking.mdwn b/open_issues/virtualization/networking.mdwn
index 7a6474a1..f8bda063 100644
--- a/open_issues/virtualization/networking.mdwn
+++ b/open_issues/virtualization/networking.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
@@ -28,3 +28,73 @@ Collection about stuff that is relevant for *virtualization* and *networking*.
[[hurd/translator/pfinet]] by setting environment variables.
Project is now part of [[Virtual_Square_View-OS]].
+# OpenVPN
+## IRC, freenode, #hurd, 2013-08-23
+ <youpi> good news
+ <youpi> with a couple small patches, openvpn does work as joe user
+## IRC, freenode, #hurd, 2013-08-30
+ <youpi> it's really cool that openvpn ended up working completely the day
+ before :)
+## IRC, freenode, #hurd, 2013-09-03
+ <_d3f> Hey guys, how did you get openvpn working on the Hurd? just curious
+ as I saw it in the GHM video
+ <_d3f> no one here who has a clue how to get *vpn working on the Hurd?
+ <braunr> _d3f: youpi did it
+ <braunr> i don't know the details
+ <_d3f> okay, I will question him when I see him around, thx. Do you know if
+ it was a lot of work to get the tun device working? Because I would like
+ to use tinc on the Hurd.
+ <braunr> _d3f: a bit but not that much either
+ <_d3f> braunr: well, okay. Do you know if the source of his 'port' is
+ online, I haven't found it :/
+ <braunr> it should be soon
+## IRC, freenode, #hurd, 2013-09-04
+ <_d3f> youpi: you are the guy who has brought openvpn to the hurd, right? I
+ would like to know how you got the tun/tap thing working as I would like
+ to use tinc on it. :)
+ <youpi> _d3f: essentially no modification of openvpn iirc
+ <youpi> just tell it to open the tun node created by pfinet
+ <youpi> and read/write it
+ <youpi> i.e. the existing generic code in place in openvpn
+ <_d3f> I will have a look at it, somekind tinc builds with the linux
+ specific device.c but I wasn't able to exchange keys. I will have a look
+ at the device handling again and try to get the pfinet tun node used.
+## IRC, freenode, #hurd, 2013-09-07
+ <d3f> anyone here knows how /dev/net is handled on the hurd? Programs using
+ it say it's not a directory. I tried creating one and setting a netdde
+ translator for a tun device in it, but this may be wrong as it doesn't
+ work
+ <teythoon> d3f: what does /dev/net do?
+ <teythoon> ah, its tun/tap stuff...
+ <d3f> on my gnu/linux it includes a tun device
+ <teythoon> right
+ <d3f> I am still reading about the Hurd and try to understand /hurd/netdde
+ and devnode but by now I am quite sure I will need those to set a tun
+ networktranslator on /dev/net/tun?
+ <teythoon> hm, I don't think netdde or devnode will be of any help
+ <teythoon> afaiui devnode makes mach devices available in the hurdish way,
+ i.e. available for lookup in the filesystem
+ <teythoon> d3f: ping youpi if he shows up, he hacked up openvpn to work on
+ the hurd
+ <d3f> yeah I know, I talked to him as I am tring to get tinc working on the
+ Hurd (tinc builds by now). I will give him a shot about creating the
+ "tun" device
diff --git a/public_hurd_boxen.mdwn b/public_hurd_boxen.mdwn
index 36e04ab1..4c7b3e24 100644
--- a/public_hurd_boxen.mdwn
+++ b/public_hurd_boxen.mdwn
@@ -29,7 +29,7 @@ image|hurd/running/qemu]].
"[[bddebian]]","goober","Debian GNU/Hurd","?"
"[[bddebian]]","grubber","Debian GNU/Hurd","Celeron 2.2 GHz; 554 MiB","Xen domU on [[zenhost]]; for experimental stuff"
"[[bddebian]]","[[zenhost]]","Debian GNU/Linux","Celeron 2.2 GHz","Xen dom0 for several hosts"
-"[[sceen]]","darnassus","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; public Hurd box; web server"
+"[[sceen]]","darnassus","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; public Hurd box; [web server]("
"[[sceen]]","ironforge","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian buildd"
"[[sceen]]","exodar","Debian GNU/Hurd","Core i5 3.1 GHz, 1.8 GiB","KVM guest on shattrath; Debian porterbox, all Debian Developers have access"
"[[sceen]]","shattrath","Debian GNU/Linux","Core i5 3.1 GHz","KVM host"
diff --git a/public_hurd_boxen/sceen.mdwn b/public_hurd_boxen/sceen.mdwn
index 25416857..b9188ffe 100644
--- a/public_hurd_boxen/sceen.mdwn
+++ b/public_hurd_boxen/sceen.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -9,3 +9,11 @@ is included in the section entitled [[GNU Free Documentation
+# IRC, freenode, #hurd, 2013-08-21
+ <braunr> i made all VMs use hugetlbfs for their physical memory
+ <braunr> i suspect a system like the hurd, with such a huge working set for
+ just about every action compared to other systems, should visibly benefit
+ from that