***Server sets mode: +nt
***Server sets mode: +nt
<damo22>so damn close to getting it working <jrtc27>well you've done the first 90%, now comes the other 90% :P <damo22>nah i did that previously, im on the last 20% of the last 90% <damo22>it basically boots, but doesnt notify to shutdown cleanly <damo22>ive been wrangling with this for months <damo22>the pci arbiter has two translators, a trivfs one for the root of its filesystem and a netfs one for the pci device tree, im not sure how it can get access to /servers/startup in S_fsys_init, ive called fsys_getroot but it doesnt seem to work <damo22>pci -> rump -> ext2fs -> exec, this is the flow of servers, but i think pci cannot inherit the disk from rump because it is started first <damo22>/servers/startup is a file on the disk <damo22>youpi seems to think i already solved this problem with rumpdisk and i need to repeat the same way <ThinkT510>have you been documenting as you go along? I'm sure hurd could do with some nice up to date documentation. Saves people from having to figure everything out all over again. <damo22>ThinkT510: if i fully understood what i was doing, i would have it finished by now <ThinkT510>that's my point. to understand what is going on things should be documented. if nobody documents anything then every time someone comes along it has to be figured out all over again. <ThinkT510>you've figured out quite a bit with the work you've done <damo22>there is documentation on the boot process, let me dig it out <ThinkT510>I'm glad there is some documentation on how things work so you're not going into this blind <ThinkT510>I've only been loosely following what is going on here and it just seemed that with all your questions that the inner workings of the hurd were not well documented <damo22>hoping that someone will give me answers so i dont have to figure it out from the code <damo22>i think the hurd is difficult to understand in general, because of its microkernel model, everything is a separate process/server <damo22>and processes have to communicate between each other <damo22>i seem to be good at reading existing code and extending it to do more things, but if i have to design something from scratch it's usually a mess <ThinkT510>I'm glad you're making progress. There seems to be little outside indication that the hurd is being developed on. I suppose it's just that they like using mailing lists and don't update the website often so I just don't see much. <youpi>damo22: rumpdisk gets a control port on ext2fs in it's trivfs_S_fsys_startup, called by ext2fs, that one is supposed to call fsys_startup on its bootstrap port, and thus hand over the control port on ext2fs <youpi>so that pci-arbiter gets the control port on ext2fs in its S_fsys_startup <youpi>then pci-arbiter, in its S_fsys_init, can call fsys_getroot, just like rumpdisk's trivfs_S_fsys_init does <youpi>and install it as CRDIR port <youpi>then the look ups should be working fine <damo22>hmm it still doesnt clean reboot <damo22>Asking all remaining processes to terminate...killall5: can't read from 5/stat <damo22>killall5: can't read from 6/stat <damo22>do i need to register the pci and rump as essential startup tasks? <youpi>as I mentioned before, yes you do <damo22>but there is a difference between proc_mark_important and startup_essential <damo22>i think the startup_essential makes it crash the whole system if one dies <damo22>`S_startup_essential_task` function thus gets called each time, and startup records each of them as essential, monitoring their death to crash the whole system. <youpi> proc_is_important (p, &essential); <youpi> start_code = end_code = 0; /* To make killall5.c consider it a <youpi>so it seems that making it proc-important should be enough <youpi>you can check in /proc/<pid>/stat for start_code / end_code <youpi>they should be 0 for pci-arbiter and rumpdisk, just like it is for ext2fs etc. <youpi>879 (-bash) S 878 879 879 0 0 0 0 0 0 0 6 1 0 0 20 0 2 0 0 158810112 851 0 134422528 135659428 0 0 0 0 0 0 0 24020 0 0 0 0 0 0 0 <youpi>1 (init) H 1 1 1 0 0 0 0 0 0 0 5 1 0 0 20 0 3 0 0 154152960 238 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 <youpi>(the second and third big numbers for bash, which are 0 for init) <damo22>err = proc_mark_important (proc); <youpi>if they don't fail, that should be enough yes <youpi>do you actually see start/end_code being zero in /proc ? <damo22>cat: /proc/5/stat: Input/output error <youpi>that's not supposed to happen <youpi>possibly the registration of pci-arbiter and rumpdisk to proc (pid, user, etc.) is not happening properly <damo22> ahcisata0 channel 5: setting WDCTL_RST failed for drive 0 <damo22>./runit: line 1: 755891 Segmentation fault <youpi>e.g. possibly process_file_gc_stat's call to proc_pid2proc is simply failing <youpi>which would be proc/info.c:S_proc_pid2proc <youpi>but better put prints to be sure what is actually happening <damo22>i cant do any more tonight, but thanks for your help, i have submitted a fix for the warning on previous patch ***Emulatorman___ is now known as Emulatorman