***Server sets mode: +nt
<damo22>where do i put mach_prints? i dont know where the rpcs are <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>i think i will add a test mode where it does not probe ahci <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>youpi: http://paste.debian.net/plain/1140067 <--- 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>I'm surprised not to find an example of returning a null port <foggy67>Is the sound now supported in the GNU/Hurd? <foggy67>Is there a special package to setup? <youpi>it's embedded in the mplayer application as built by Robert Millan <youpi>damo22: Mmm, I do find an instance in diskfs_S_fsys_getroot and diskfs_S_io_get_icky_async_id <youpi>I don't think there is much difference between using COPY_SEND or MOVE_SEND here <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>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>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>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?