IRC channel logs


back to list of logs

<oaken-source>hey, is there anyone already working on a riscv port of the hurd?
***john__ is now known as gaqwas
<damo22>oaken-sauce: not that i know of
<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 ?
<youpi>is machdev_argv non-null ?
<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()
<damo22>do i need to update my install?
<youpi>it does
<youpi>through its _hurd_new_proc_init call
<youpi>no need to upgrade
<youpi>*no* process would be calling _proc_set_arg_location otherwise
<damo22>hmm ok
<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>sorry not sure
<damo22>youpi: get_vector failed on ESRCH
<damo22>i fixed the EIO, but it doesnt populate the field
<damo22>the vector of strings is empty
<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 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
<oaken-source>jrtc27: thanks for the clarification
<jrtc27>FYI this is the "vendor" component of the field
<jrtc27>it's cpu-vendor-os
<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