<damo22>ok sounds good, i will fix the delay and the setting of importance this evening ***Server sets mode: +nt
<damo22>it seems that trivfs_S_fsys_init is running for rumpdisk's machdev but pci-arbiter's machdev is not getting called <damo22>do i need to chain them together somehow? <damo22>eg, do i call fsys_init() inside trivfs_S_fsys_init() ? <youpi>damo22: just like libdiskfs was made to, yes <damo22>youpi: after _hurd_init () runs , i am now trying to get the bootstrap port inside rumpdisk, but i think its null <damo22>so im not sure how to get the right port to call the fsys_init <damo22>maybe i need to call fsys_init after get_priv, just before rump_init since i have the bootstrap port there? <damo22>Hurd server bootstrap: ext2fs[part:2:device:wd0] exec startup proc auth. <damo22>machdev: S_fsys_init: /dev/rumpdisk <damo22>At this point it hangs trying to call fsys_init a second time <damo22>youpi: what would be the right port to call fsys_init on inside trivfs_S_fsys_init ? i am calling task_get_bootstrap_port(mach_task_self (), &bootstrap); in there but its null <damo22>does something clear out the bootstrap port by the time startup is run? <youpi>I don't see how the bootstrap port could be getting cleared <youpi>I haven't followed what you did, but did you put the fsys_init call in your S_fsys_init stub? <youpi>at that point the bootstrap port should be there <youpi>I mean whatever handles the fsys_init call coming from ext2fs <youpi>rumpdisk is using libtrivfs only, isn't it? <youpi>just like libdiskfs' diskfs_S_fsys_init forwards the call <damo22>which implements the trivfs_S_fsys_init() <youpi>then that's it's fsys_init stub that should forwqrd <damo22>im hitting that function call, but i dont know what port to use for fsys_init(... , <damo22>to do the RPC back to the pci server <youpi>just like it's done in libdiskfs <damo22>the way it is done in libdiskfs makes no sense to me, there seems to be a tricky inheritance of which server is the parent <damo22>and when i try to copy it, i get NULL for the bootstrap port <youpi>was the bootstrap port set for rumpdisk? <youpi>I don't remember which line was added to do this for ext2fs <youpi>possibly that's missing for the pci-arbiter - rumpdisk relation <youpi>it's rumpdisk that does it iirc <youpi>setting the bootstrap port of the ext2fs task, before letting it continue etc. <damo22>machdev sets special port TASK_BOOTSTRAP_PORT <damo22>and i am resuming both servers using the same code <youpi>you could put debugging prints in gnumach's task_set_special_port, to check what is really happening <youpi>(and on the get, to see the reads of the bootstrap port, not only the writes) <damo22>i tried calling fsys_init on the control_port in libmachdev, i got EOPNOTSUPP ***janneke_ is now known as janneke`
***TigerbotHesh is now known as Guest1351
***Emulatorman___ is now known as Emulatorman
***janneke` is now known as janneke