IRC channel logs


back to list of logs

<youpi>I don't have time to fixup patches
<youpi>let alone test them
<youpi>(also, the more I do, the less people do, the less people learn, and thus the less people will do long-term)
<jrtc27>gnu_srs1: maybe linus should write all the code for linux rather than have people write patches he then asks to be fixed?
***Server sets mode: +nt
<damo22>i dont mind writing patches, i like the feedback from youpi
<damo22>it is very high quality feedback, ends up with solid final outcome instead of half baked attempts getting merged
<damo22>i am learning how to rebase and git add -p is very useful
<damo22>youpi: i iterated over all the pids except 1 and called proc_child in launch_core_servers for all the essential tasks except kernel, proc and startup, but i got /hurd/startup: /libexec/console-run: No such file or directory
***kilobug_ is now known as kilobug
<damo22>hmm i get that same error when i install savannah's startup to /hurd/startup
<damo22>there must be a debian specific patch
<youpi>- argv[0] = "/libexec/console-run";
<youpi>+ argv[0] = "/sbin/console-run";
<youpi>see the TODO in libexec.patch
<damo22>yeah i patched it locally and my startup now works but my proc_child thing seems to have no effect
<youpi>perhaps really put debugging prints in procfs to check what precisely happens with the failure
<youpi>iterating over essential tasks is still probably a better idea than hardcoding the list of bootstrap tasks
<damo22>it does not even call process_file_gc_stat() it dies before that and cat returns i/o error
<damo22> 90<--89(pid716)->io_stat () = 0 {0 0 0 2002528766 0 0 0 33060 0 -1 0 0 0 0 0 0
<damo22> 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0}
<damo22>i think the name is empty string and something is parsing the name
<damo22>hmm not really, io_read is failing
<damo22>EIO 1 <-- second EIO in process.c
<damo22> if ((proc_stat_flags (file->ps) & file->desc->needs) != file->desc->needs)
<damo22> {
<damo22> mach_print("EIO 1\n");
<damo22>how do i get the names of the bootstrap tasks so i can call proc_set_exe on them in startup?
<damo22>currently they are hardcoded and assumed from the fixed list
***azeem_ is now known as azeem
<youpi>damo22: ideally the bootstrap translators would call proc_set_exe themselves
<damo22>i called proc_set_exe in libmachdev individually
<youpi>startup doesn't have the name info
<damo22>but they didnt get set
<youpi>(unless hardcoded)
<youpi>did you call it from fs_init?
<youpi>so that proc is set up at that point
<youpi>perhaps put prints to check why it didn't happen
<damo22>it seems like the procserver is not the same as startup
<damo22>so it gets reset there too
<damo22>is launch_core_servers called before fsys_init is called the first time?
***DiffieHellman_ is now known as DiffieHellman
<youpi>damo22: cf the wiki bootstrap page: it's launch_core_servers which triggers the fsys_init call chain
***vup is now known as __vupbot
***__vupbot is now known as vup
<damo22>YAY rumpdisk is upstreamed
***dragestil_ is now known as dragestil
<Pellescours>yay awesome, congratulation
<damo22>thank gnu Pellescours
<damo22>my friend was more impressed that i could withstand the gnu coding style