IRC channel logs


back to list of logs

<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>inside trivfs_S_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
<damo22>stub? do you mean netfs?
<youpi>I mean whatever handles the fsys_init call coming from ext2fs
<youpi>rumpdisk is using libtrivfs only, isn't it?
<youpi>then that's it
<youpi>just like libdiskfs' diskfs_S_fsys_init forwards the call
<youpi>libtrivfs's should as well
<damo22>it uses libmachdev
<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
<damo22>i dont recall touching ext2fs
<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>when resuming the task
<youpi>that should be it
<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