[12:54] <keesj> :.. not good http://paste-it.net/raw/public/q26a6ac/ ..
[12:58] <keesj> 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] <arekm> you need a patch that ignores this error instead of failing
[13:13] <arekm> http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/~checkout~/SOURCES/upstart-oomfail.patch?rev=1.1;content-type=text%2Fplain
[13:14] <ion_> CVS? *shiver*
[13:17] <arekm> cvs sill works you know
[13:17] <ion_> FSVO works
[13:28] <keesj> arekm: thanks 
[13:57] <keesj> cvs never left me down
[13:58] <keesj> unlike upstart 
[13:58] <keesj> right now :p
[14:11] <arekm> upstart is well, too new to be marked as "good"
[14:18] <keesj> 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] <keesj> hmm , two more problems
[15:11] <suihkulokki> keesj: kvm/qemu are convinient when debugging init
[15:12] <keesj> typing start with no argument segfaults and initctl list looks very bad
[15:12] <keesj> http://paste-it.net/raw/public/j18a061/
[15:13] <keesj> suihkulokki: I also have a qemu build running with a nfs export
[15:14] <keesj> I guess there must be a way to attach gdb to the init process when the kernel starts
[15:15] <suihkulokki> keesj: qemu -p
[15:26] <keesj> suihkulokki: I do full system emulation (so also a kernel) als upstart doens't like not being something else then p1 
[15:27] <keesj> it's not that easy :p
[15:44] <suihkulokki> keesj: have you tried? qemu -p works well system qemu. you can stop anywhere in the guest execution.
[15:54] <keesj> so that would be the kernel right. 
[15:57] <keesj> 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] <sadmac2> ion_: ping
[21:13] <ion_> sadmac2: pong
[21:13] <sadmac2> ion_: I'm working on a waitfd implementation, was wondering if you wanted to comment on how the api should look
[21:13] <ion_> I could take a look.
[21:15] <sadmac2> ion_: its not really a code matter. just whatever you'd like the function signature to look like
[21:17] <ion_> 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] <sadmac2> 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] <ion_> Alright, sounds good.
[21:20] <sadmac2> 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] <sadmac2> ?
[21:23] <ion_> waitfd (..., {pid0, pid1, pid2, NULL}); or waitfd (..., pid0, pid1, pid2) perhaps?
[21:23] <sadmac2> ion_: varargs? in MY system call?
[21:23] <ion_> Thus the former one. :-)
[21:24] <sadmac2> what I dislike there is that it doesn't map easily to the underlying wait4 call
[21:28] <ion_> 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] <sadmac2> ion_: that's a given
[21:30] <sadmac2> ion_: right now you can wait on all, a specific pid, or a group
[21:30] <sadmac2> you just can't do N specific pids
[21:30] <ion_> Yeah, i meant that as an answer to how to do N specific pids
[21:31] <ion_> Capture all, filter them in the app
[21:33] <sadmac2> ion_: certainly it can be done. is it best?
[21:38] <ion_> int fd = waitfd (...); ioctl (fd, WAITFDADDPID, pid0); ... :-)
[21:38] <sadmac2> ion_: no
[21:38] <sadmac2> ion_: the array thing is more likely
[21:44] <ion_> Keybuk probably would give better input.
[21:45] <sadmac2> indeed
[21:46] <sadmac2> but I haven't seen him today
[21:46] <ion_> He’s on a leave AFAIK.
[21:46] <sadmac2> ah
[21:47] <ion_> I’d spend *more* time on IRC when on a leave. :-P
[21:47] <sadmac2> heh
[22:26] <sadmac2> ion_: fun disaster case: what does read(mywaitfd) return when wait() would return ECHILD?
[22:33] <ion_> Hmm :-)
[22:33] <sadmac2> ion_: the read manpage says read can return "other things" depending on what its hooked to.
[22:34] <ion_> siginfo_t with si_pid = 0 or something like that?
[22:34] <sadmac2> no, I think we should throw an error.
[22:35] <sadmac2> timerfd already has a custom error code entry, this will be no different.
[22:35] <ion_> Alright