IRC channel logs


back to list of logs

***Server sets mode: +nt
<youpi>'night :)
<youpi>(though not yet, but soon)
<damo22>where do i put mach_prints? i dont know where the rpcs are
<damo22>do you mean in S_
<youpi>that's the stubs called by the mig server
<damo22>i think i know where it could be failing
<damo22>im not sure if rumpdisk falls back to x86
<damo22>or only uses hurd
<damo22>for libpciaccess
<damo22>i think i will add a test mode where it does not probe ahci
*youpi powerdown
<damo22>start rumpdisk: dummy rumpdisk
<damo22>pci system inited, rump should work
<damo22>im building gnumach-sv from master, plus debian ramdisk + noahci patch
<damo22>it no longer crashes, it just hangs after resuming the next task
<damo22>hm i think my ext2fs.static needs to be recompiled with my new libstore
<damo22>its failing in trivfs_startup
<damo22>youpi: <--- its hung in trivfs_startup() can you tell if i am passing the wrong port to "bootstrap" ? i am returning the send right from resume_bootstrap_server() and assigning it to bootstrap port... i cant remember what i am supposed to use
<youpi>damo22: why implementing trivfs_S_fsys_startup?
<youpi>ah, I guess that's because it gets called in diskfs_startup_diskfs
<youpi>I guess setting MACH_MSG_TYPE_MOVE_SEND is incorrect when returning a null port
<youpi>MACH_MSG_TYPE_PORT_NAME could be valid
<youpi>but I don't see it used
<youpi>I'm surprised not to find an example of returning a null port
<foggy67>Is the sound now supported in the GNU/Hurd?
<youpi>we have a prototype
<foggy67>Is there a special package to setup?
<youpi>it's embedded in the mplayer application as built by Robert Millan
<foggy67>sudo apt-get install mplayer?
<youpi>damo22: Mmm, I do find an instance in diskfs_S_fsys_getroot and diskfs_S_io_get_icky_async_id
<youpi>using COPY_SEND
<youpi>I don't think there is much difference between using COPY_SEND or MOVE_SEND here
<youpi>(for a null port)
<youpi>so I'd say your version should be fine enough
<foggy67>youpi : mplayer from Debian Hurd repository?
<youpi>foggy67: from Robert Millan's reporisotry
<youpi>damo22: you seem very confused on what "boostrap port" is
<youpi>it's a relative notion
<youpi>here rump has its bootstrap port NULL for now
<youpi>since it's the very first translator
<youpi>rump however has to give ext2fs a bootstrap port, for ext2fs to use fsys_getpriv on it to get the host_priv and dev_master ports
<youpi>put another way, there is no reason to insis on trying to pass a non-null port to trivfs_startup inside rump
<youpi>for now there is *no* bootstrap port for the rump translator
<youpi>but rump creates a bootstrap port for ext2fs
<youpi>which is what resume_bootstrap_server does: create a port, set it as bootstrap port in ext2fs
<youpi>but it should *not* return it
<youpi>it's only meant for ext2fs
<youpi>later on, when we have a bootstrap pci-arbiter, pci-arbiter will create a port and set it as bootstrap port for rump
<youpi>but then it's pci-arbiter which will not have a bootstrap port
<youpi>but create one for rump
<youpi>see what trivfs_startup does with the bootstrap port, it tries to contact it, calling it "our parent"
<youpi>what you did is basically making rump contact itself as one's parent, that can't make sense :)
***pie_ is now known as pie_[bnc]
<rekado_>I’m a bit confused by the build system for netdde
***rekado_ is now known as rekado
<rekado>I’m a bit confused by the build system for netdde
<rekado>it looks like libdde_linux26 assumes that we copy headers to a build directory first…? It doesn’t seem to take care of this on its own.
<rekado>I guess I just made the mistake of setting PKGDIR which has to be different for libdde_linux26 and netdde
<rekado>yeah, that was the problem. Sorry for the noise.
<damo22>youpi: so does that mean there is no parent of rump because it is the bootstrap translator?
<damo22>(in the current approach without the arbiter)
<damo22>what will happen if fsys_startup is called on MACH_PORT_NULL ?
<youpi>damo22: (bootstrap): yes, that's it
<youpi>calling fsys_startup on a null port would crash
<youpi>that's why translators test against it
<youpi>(well, not crash, fsys_startup would just return an error)
***Viper is now known as GNU[BDC]
***GNU[BDC] is now known as Out`Of`Control
<damo22>youpi: im confused how to handle it, because "fsys" in machdev_trivfs_server needs to be used after the trivfs_startup call
<damo22>do i just ignore if it returns error?