***Server sets mode: +nt
<damo22>although i am still unsure how ext2fs will be able to see /dev when / is not mounted <damo22>the process for ext2fs is to mount part:2:device:@/dev/rump:/dev/wd0 onto / <damo22>do we need another special designation for booting rump via its special port? eg when --fs-server-task=x is passed, it assumes part:2:device:/dev/wd0 is the BSD name only? <damo22>i think we can use part:2: device:@bootstrap:/dev/wd0 <youpi>damo22: it doesn't "see" /dev, it uses the bootstrap port to call device_open() on it <youpi>that's precisely the difference between setting root=device:hd0 and root=file:/dev/hd0 <youpi>here it could be root=part:2:device:/dev/wd0 <youpi>it doesn't need to be given a different master device port <youpi>since it's the bootstrap port that it will use as the device port on which to call device_open() <youpi>device:@bootstrap would be a completely redundant designation :) ext2fs already uses its bootstrap port to call open_device() <youpi>ah, sorry, I collapsed the device master port and the bootstrap port <youpi>that's the problem when writing things from memory only <youpi>okay, unfortunately the absence of the bootstrap port is sometimes used as "I'm the bootstrap filesystem", see diskfs_startup_diskfs, so we need to fix that first <youpi>another possibility is to add a boot feature to gnu mach to create a port pair, give the receive right to one module, and the send right to another module <youpi>the rump module would get the receive right, and run the device server on it <youpi>and the send right would be given to ext2fs's device-master-port option <rekado>I’m packaging the dde things for Guix now; starting with libports I notice that HURDLIBS insists on using libraries from the source tree. <rekado>I’m packaging the dde things for Guix now; starting with libports I notice that HURDLIBS insists on using libraries from the source tree. <rekado>I’m patching the Makefile to use the shared libraries that are on LIBRARY_PATH <youpi>normally it'd indeed use what has been just built right before <youpi>and not what happens to be provided by the system <rekado>we’re building the libraries separately, so there isn’t anything else that has been built right before <rekado>the other libs are already installed to their own prefix directory <youpi>I don't understand what you are doing <youpi>are you trying to build the hurd/ repository only partially? <rekado>perhaps it is a bad idea to have a separate package for libports, libmachdev, etc <rekado>I should just build it all together <youpi>since it's the same source package upstraem, better not make it a different source package downstream yes <youpi>that would usually break with most software build systems <rekado>since the DDE stuff is in the incubator repository, should I build all of the Hurd from the “dde” branch in incubator.git? <rekado>(I was assuming I could just build the dde libraries from incubator separately and combine them with our Hurd package) <youpi>nobody took the time to make it a separate build tree <youpi>so it needs to be built along the hurd tree <youpi>what we do in debian is to put them together <youpi>and add the dde paths to the root Makefile <youpi>damo22: creating a send/receive pair in the kernel should be fine enough, but convincing libtrivfs to use that instead of its own port looks hairy <youpi>it seems easier, in diskfs_init_main, in the boot_filesystem case, to call fsys_getpriv() on the bootstrap port (like _diskfs_boot_privports does), and still set *bootstrap to MACH_PORT_NULL like already done ATM <youpi>and in rumpdisk, to indeed create a port+class+bucket <youpi>whose only purpose is to answer that fsys_getpriv call <youpi>like is done in libdiskfs/boot-start.c <damo22>should i post it for a quick glance? <youpi>(yes, it's better to have an intermediate port, because everything else (startup etc.) are used to call fsys_getpriv on the bootstrap port to access the device master port <damo22>that way, libmachdev can resume a bootstrapped server depending on how the master device is opened? <youpi>now what's missing is the server part for the server_info port <youpi>to answer fsys_getpriv, like boot-start.c does <youpi>sure, understood that part from the API change :) <damo22>i need to use proper option parsing <damo22>but i dont know how i could pass the /dev/rump part of the master device to device_open <youpi>it seems easier, in diskfs_init_main, in the boot_filesystem case, to call fsys_getpriv() on the bootstrap port (like _diskfs_boot_privports does), and still set *bootstrap to MACH_PORT_NULL like already done ATM <youpi>that way libdiskfs will get the master port from the bootstrap port <youpi>and device:/dev/wd0 will naturally resolve through rump <youpi>as well as all other such device_open() in userland <youpi>including the storeio translators in /de <youpi>damo22: ah, there was a misunderstanding in your code, though: here you are creating a diskfs port and passing it as a bootstrap port <youpi>and thus in libdiskfs's diskfs_init_main, you can set the bootstrap port as device master port <youpi>but what I wrote above is that other tools seem to go through a fsys_getpriv() call <janneke>rekado: thanks for looking into this! <youpi>so it'd have to go through another port class/bucket to handle that and return the device master port <youpi>both on the resume_bootstrap_server side and on the diskfs_init_main side <rekado>youpi: this seems to be working. Thanks for the help! <youpi>that being said, on the libmachdev side it can be made simpler by not using an intermediate port <youpi>and just make its trivfs server also answer fsys_getpriv requests <youpi>that would simply return the same port <youpi>i.e. libdiskfs would get a bootstrap port that is the diskfs port, call fsys_getpriv on it (like other tools are doing), only to get the same port, and use that as device master port <youpi>that way we keep the principles like other tools, while still keeping a simple code on the libmachdev side <youpi>I guess from the code you have you merely need to add the S_fsys_getpriv() function and that'd be it <youpi>trivfs_S_fsys_getpriv more precisely <youpi>(since apparently it's that function name which has a weak definition in libdiskfs) <damo22>youpi: so i just need to implement trivfs_S_fsys_getpriv() in libmachdev? would i call fsys_getpriv in rumpdisk then ? <youpi>I'd say so yes i nlibmachdev <youpi>you don't need to implement it in rumpdisk <damo22>fsys_getpriv (bootstrap, &host_priv, &device_master, &parent_task); dont need to call this in rumpdisk? <youpi>no it's libdiskfs that will need that <youpi>libmachdev *is* the device master <damo22>ok, so does libdiskfs already do that? <youpi>so its trivfs_S_fsys_getpriv just needs to return the RPC port as master device port <youpi>no it doesn't yet, see what I wrote above <youpi> libdiskfs would get a bootstrap port that is the diskfs port, call fsys_getpriv on it (like other tools are doing), only to get the same port, and use that as device master port <youpi> libdiskfs would get a bootstrap port that is the libmachdev port, call fsys_getpriv on it (like other tools are doing), only to get the same port, and use that as device master port <youpi> libdiskfs would get a bootstrap port that is the trivfs port, call fsys_getpriv on it (like other tools are doing), only to get the same port, and use that as device master port <youpi>in that libmachdev uses trivfs to implement its appearance in /dev/rump <youpi>but here we make it show up as bootstrap port <damo22>is it some handle into the kernel? <youpi>damo22: it's the privileged port to do i/o operations for instance, yes <youpi>I'd say return an error if the pointer is not NULL <youpi>and make libdiskfs pass NULL <youpi>possibly we'd want to add the support later, i.e. make rump get the host port from its command line like ext2fs current is doing <youpi>and let libdiskfs get it from there instead of the ext2fs command line <youpi>but that's more than we need now <youpi>and possibly we won't ever need that <youpi>oh, wait, rump does need that to be able to do I/O <youpi>so you do need to add a parameter to get it, like ext2fs does <youpi>and set _hurd_host_priv with it <youpi>so that libpciaccess can call ioperm() etc. <youpi>so I'd say make libmachdev return a new send right on_hurd_host_priv like get_privileged_ports is doing <youpi>since you'll already have had to have that port ready for libpciaccess <damo22>was thinking of making bootstrap port a global variable in libmachdev since its used all over the place and in the trivfs_S_fsys_... call but isnt passed in <damo22>it would simplify the api to have a setter for it and call that at the start when its needed <youpi>I don't really know why it's not in the libdiskfs case <youpi>but I guess it's like that for some reason <youpi>I don't think you need it beyond machdev_trivfs_init and machdev_trivfs_server <youpi>so I'd say keep coherent with libdiskfs <damo22>but i need to know the bootstrap port in trivfs_S_fsys_getpriv <damo22>to check if the bootstrap is non null to know if it is supposed to be a supported op <youpi>you can simply just always support it <youpi>from the point of view of libmachdev, the host port is what it got, and the device master port is itself <damo22>but doesnt that mean anyone can bootstrap the system at any time by calling the api <youpi>what problem does that cause? <youpi>using that API will only return the same privilege <damo22>get_privileged_ports (host_priv, 0); dev_master = bootstrap; <--- why wouldnt that work <damo22>and just make bootstrap globally available to the S_ function <youpi>I don't understand why you'd want to use the bootstrap port <youpi>here the bootstrap port is rump's bootstrap port <youpi>not the bootstrap port it passes to ext2fs <youpi>what you could try to pass from fsys_getpriv is "right" <youpi>created in resume_bootstrap_server <youpi>but you can also just recreate another port inside fsys_getpriv <youpi>just like you did in resume_bootstrap_server <youpi>since the trivfs_S_fsys_getpriv gives you the cntl poniter, not the port that lead to it <youpi>you could bypass that translation step, but that'd bring build hairiness <youpi>while you can as well just create another port <damo22>i dont know what the diskfs_cntl pointer is <youpi>trivfs_S_fsys_getpriv (struct trivfs_control *cntl, <youpi>it's the structure behind the port <youpi>libport translates that into a potnier to some structure <youpi>whatever the user of libports wants it to <damo22>or can i just not worry about it <youpi>I would have thought it'd be documented somewhere in the hurd info pages <youpi>basicallty, it's what you get when you start a translator <youpi>and you can control the translator with the fsys interface <damo22>its like im asking what is (void *) <damo22>its a transparent pointer to some structure <rekado>janneke: when I start guix-daemon in the Hurd VM it tells me that the bootstrap binaries cannot be found. <rekado>janneke: should they already be included? Or did I do something wrong? <rekado>I just ran “guix-daemon”, nothing else <janneke>fwiw, i'm still working on a "working" rewrite for wip-hurd-vm; i'm surprised you actually got something built <janneke>what commit did you use to build the VM? <janneke>terribly sorry about all this; we built the VM using a cross-built kludge; that civodul cleaned up real nicely -- sadly that cleanup together with a core-updates rebase broke the build badly, i've been on it for over a day now :-( <rekado>I built the VM on 4e841d569bcedf999d0a78c90f4e71b6ec51a4cc (Efraim’s “fix typo” commit) <janneke>rekado: hmm, i see no obvious reason why that would not work <janneke>rekado: i did make a couple of cross-build fixes though, after that <janneke>notably: wrap-program uses a the build bash instead of the host bash <civodul>janneke: ouch, wrap-program has a hard-coded (which "bash") <civodul>the right thing would be to pick it up from #:inputs <janneke>civodul: yeah, and touching wrap-program rebuilds a few things ;) *janneke finds a 4e841d569bcedf999d0a78c90f4e71b6ec51a4cc VM and spins it up for a test <janneke>rekado: hmm, the daemon starts for me; it only complains about using --build-users-group <janneke>rekado: ah, when i say: "guix build hello", it complains about bootstrap tar, right <janneke>rekado: i have just reset wip-hurd-vm and that should give you working daemon <janneke>i reverted some patches and added two hacks to get it into working state -- not really happy with that; that needs some attention <janneke>i'm going to try your patch right away! <rekado>I don’t know if DDE requires extra configuration in the VM <rekado>my patch only makes sure that its libraries are built and installed. <janneke>good, yes that's why i waited to apply it <janneke>i'd like to see if this fixes incoming connections <janneke>or possibly fixes the EOF problem that we have been stuck on when attempting to build `hello' ***DNS is now known as SND
<youpi>gnu_srs1: it seems I can't connect to the mahler host any more, could you have a look? ***Emulatorman_ is now known as Emulatorman
<gnu_srs1>youpi: Seems like a disk crash. How to check it. I'm remote, not having physical access. ls /home; ls: reading directory '/home': Input/output error <gnu_srs1> / is not affected, that's another disk. <youpi>gnu_srs1: ok, that looks like a faulty cable <youpi>not something that can be fixed remotely then :/ <gnu_srs1>youpi: Should I unmount sdb in order not to overflow the log files? <youpi>possibly it'll be seen as busy, you can try umount -l