<oaken-source>hey, is there anyone already working on a riscv port of the hurd? ***john__ is now known as gaqwas
<damo22>but it could make sense to make it work on real hardware <damo22>im working on fixing the x86 drivers so it boots without linux code <damo22>we are using netbsd rump (userspace drivers) <damo22>process_file_get_contents: EIO (statflags 0x4e69 != 0x6e69) <damo22>looks like the stat flag missing is 0x2000 <damo22>#define PSTAT_ARGS 0x02000 /* The process's args */ <oaken-source>I think my efforts are stalling at the first hurdle of defining an appropriate target triplet and configuring gcc support for it :| <damo22>oaken-source: i386-gnu is the triplet for hurd on x86 (32 bit) <damo22>youpi: somehow the PSTAT_ARGS flag is not being set on rumpdisk process <damo22> __proc_set_arg_locations (procserver, <damo22> _hide_arguments ? 0 : (vm_address_t) argv, <damo22> _hide_environment ? 0 : (vm_address_t) __environ); this is not being called on _hurd_init() <youpi>damo22: does trivfs_S_fsys_init get a non-null procserver port ? <damo22>i think the bug is tracked down to S_proc_getprocargs: return get_string_array (p->p_task, p->p_argv, (vm_address_t *) buf, buflen); fails <damo22>youpi: btw my version of glibc has the old _hurd_init() and it does not call _proc_set_arg_locations() <youpi>through its _hurd_new_proc_init call <youpi>*no* process would be calling _proc_set_arg_location otherwise <damo22>i dont understand get_string_array <damo22>if the first string is null, wont it fail and cause ESRCH? <oaken-source>damo22: i386-gnu, or i386-pc-gnu? is there a tangible difference? <damo22>youpi: get_vector failed on ESRCH <damo22>i fixed the EIO, but it doesnt populate the field <oaken-source>It's becoming clear that I have little chance of succeeding porting hurd to riscv with my current level of knowledge of how gcc/glibc and the mach/hurd headers work together. any recommended reading? <oaken-source>I'm having trouble particularily with the sysdeps structure of glibc <oaken-source>I found the documentation recommendations on gnu.org. that should probably get me started. <jrtc27>oaken-source: for i386/x86_64, the pc is implicit <jrtc27>pretty much every other triple has an implicit unknown instead <jrtc27>following the scheme, hurd for 64-bit riscv would be riscv64-gnu <jrtc27>which is implicitly riscv64-unknown-gnu <jrtc27>FYI this is the "vendor" component of the field <jrtc27>(though "os" can sometimes include an additional -abi, e.g. it's linux-gnu to distinguish from linux-musl or linux-uclibc) <oaken-source>does it make any difference whether the vendor is 'pc' or 'unknown'? <jrtc27>you might confuse the odd thing if you did i386-unknown or riscv64-pc, but no, it's basically pointless historical junk <oaken-source>I've just read the history of hurd on mach vs. hurd on other microkernels. absolutely fascinating. <oaken-source>I can't believe thah the hurd on L4 project has been abandoned in 2005! I thought that L4 is a relatively recent project. <oaken-source>I've seen some talks on L4 on the odd systems conference