[12:54] :.. not good http://paste-it.net/raw/public/q26a6ac/ .. [12:58] proc is not mounted so I guess it's normal that I can't open "/proc/%d/oom_adj" whatever that is :P [13:12] you need a patch that ignores this error instead of failing [13:13] http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/SOURCES/upstart-oomfail.patch?rev=1.1;content-type=text%2Fplain [13:14] CVS? *shiver* [13:17] cvs sill works you know [13:17] FSVO works [13:28] arekm: thanks [13:57] cvs never left me down [13:58] unlike upstart [13:58] right now :p [14:11] upstart is well, too new to be marked as "good" [14:18] lol , it's hard to debug the init proccess. for the kernel i use jtag+openocd and for userland many tricks but the "init" process is just a pain [15:09] hmm , two more problems [15:11] keesj: kvm/qemu are convinient when debugging init [15:12] typing start with no argument segfaults and initctl list looks very bad [15:12] http://paste-it.net/raw/public/j18a061/ [15:13] suihkulokki: I also have a qemu build running with a nfs export [15:14] I guess there must be a way to attach gdb to the init process when the kernel starts [15:15] keesj: qemu -p [15:26] suihkulokki: I do full system emulation (so also a kernel) als upstart doens't like not being something else then p1 [15:27] it's not that easy :p [15:44] keesj: have you tried? qemu -p works well system qemu. you can stop anywhere in the guest execution. [15:54] so that would be the kernel right. [15:57] I do something like this http://paste-it.net/raw/public/ve3bd51/ starting with -p doens't have effect and I need to switch to the qemu control (control-a c) and type gdbserver 1234 to start it :p [16:02] * suihkulokki is having trouble shutting down system cleanly using upstart native mode [20:57] ion_: ping [21:13] sadmac2: pong [21:13] ion_: I'm working on a waitfd implementation, was wondering if you wanted to comment on how the api should look [21:13] I could take a look. [21:15] ion_: its not really a code matter. just whatever you'd like the function signature to look like [21:17] I’m afraid i haven’t thought of waitfd enough to have any ideas, but if you shared your ideas, i might have thoughts. :-) [21:18] ion_: right now it takes basically the same arguments as waitpid, and the descriptor spits out a stream of siginfos that would come from calling waitpid repeatedly. [21:19] Alright, sounds good. [21:20] ion_: the interesting bits are: is specifying such a descriptor for one process useful, and do we need a way to specify n specific processes [21:20] ? [21:23] waitfd (..., {pid0, pid1, pid2, NULL}); or waitfd (..., pid0, pid1, pid2) perhaps? [21:23] ion_: varargs? in MY system call? [21:23] Thus the former one. :-) [21:24] what I dislike there is that it doesn't map easily to the underlying wait4 call [21:28] How about just waitfd (-1, ...), have it spout siginfo_ts for all pids and filter them as appropriate in userspace, in case the app is interested of multiple pids? [21:30] ion_: that's a given [21:30] ion_: right now you can wait on all, a specific pid, or a group [21:30] you just can't do N specific pids [21:30] Yeah, i meant that as an answer to how to do N specific pids [21:31] Capture all, filter them in the app [21:33] ion_: certainly it can be done. is it best? [21:38] int fd = waitfd (...); ioctl (fd, WAITFDADDPID, pid0); ... :-) [21:38] ion_: no [21:38] ion_: the array thing is more likely [21:44] Keybuk probably would give better input. [21:45] indeed [21:46] but I haven't seen him today [21:46] He’s on a leave AFAIK. [21:46] ah [21:47] I’d spend *more* time on IRC when on a leave. :-P [21:47] heh [22:26] ion_: fun disaster case: what does read(mywaitfd) return when wait() would return ECHILD? [22:33] Hmm :-) [22:33] ion_: the read manpage says read can return "other things" depending on what its hooked to. [22:34] siginfo_t with si_pid = 0 or something like that? [22:34] no, I think we should throw an error. [22:35] timerfd already has a custom error code entry, this will be no different. [22:35] Alright