IRC channel logs
2025-08-02.log
back to list of logs
<damo22>rumpdisk works on my AMD FCH, but now the issue is the realtek 8168 nic does not work <damo22>so i have disk but no network on native HP T620 <azert>damo22: cool! The “re” driver doesn’t work with your rumpnet? <damo22>it should but it needs to be built as part of rump, so far only wm is compiled <damo22>i havent worked out how to add the rest of the nic support <azert>I wonder if eventually it will be possible to link these drivers at runtime with dl_load <damo22>rump_allserver already supports that <damo22>but something needs to tell it what driver to link, it doesnt link on probe <azert>something like udev in Linux <damo22>if they are individual dynamic libs, they can be loaded at runtime as needed? <damo22>even if the binary is linked to all of them <damo22>it will only load the ones it needs <azert>no, you can either link at compile time or at run time <damo22>if 1 isnt executed, it will only load 2 right?? <azert>there are two ways of doing dynamic linking <azert>the one you do with -lrump1 -lrump2 will load everything <azert>the second way is to use dl_load function <damo22>the problem is the probe functions are in the libs <damo22>so you cant tell if you have the device present without running the probe function in every lib <azert>What Linux does is to have a software that checks the pci-ids and then load the module according to a table <damo22>i dont have bandwidth to reinvent udev <damo22>i think for now we can load them all like netdde does <damo22>even so, we need to actually do work in netbsd to make this work <damo22>the current rump is a proof of concept, Kantee did not finish it <azert>NetBSD doesn’t use udev for kernel modules. It stores the pci ids in the .modinfo section of each elf module and quickly scans the kernel module directory at prove time <azert>if that is implemented in rump, probably it could do the same <azert>but, yeah, this is more like a wishlist then an important thing to implement <azert>for usb, for instance, this could be preferable to splitting the stack <damo22>eh? no, we need the stack to function as controller + peripheral <damo22>otherwise we can only attach one peripheral <azert>I think that netbsd is a bit more flexible than thay <azert>it will allow for instance to attach libusb devices <azert>another option that isn’t an alternative (can be provided at the same time) is to dl_load the drivers from a specific directory as a loadable module <azert>like we were just discussing <damo22>but that still means the one translator looks after all of usb <azert>yes, except the ones implemented as ugen <azert>I think it’s still an elegant solution <azert>and probably also more compatible <damo22>the ugen way is more versatile and does not interrupt the controller from hosting the pci devices, even if a peripheral fails it can do a bus reset and drop the driver process <damo22>i mean just for the bad peripheral <azert>both have advantages and disadvantages <azert>for instance the dl_load is surely more lightweight <damo22>i got ugen0 to be probed within rump, but i could not seem to expose /dev/ugen to rump <youpi>btw, at some point we need to fix rump's memory-eating behavior ;) <youpi>otherwise the multiplication of rump processes will pose problem ;) <youpi>debian gnu/hurd 2025 will already pose a bit of problem with both rumpdisk and rumpusbdisk <damo22>but if usb is hosting / fs then it cannot be swapped out instead of ahci <damo22>maybe we need gnumach to know which process is hosting / ? <youpi>that's the wire all call that is already there <youpi>processes can call it when they are in the bootstrap chain <damo22>so we make wire all only work for bootstrap processes? <youpi>actually it's also needed for non-bootstrap processes, when the disk driver is loaded after nfs / initrd-hosted / is started <damo22>i guess we just dont call it unless its needed <damo22>i am confused why rumpnet fails when i dont call it <youpi>we spuriously call it when installing from a USB cd to a non-USB disk for instance <youpi>probably it's missing some wire call somewhere, for the buffers used for dma <damo22>yea but rumpcomp_dmalloc uses vm_alllocate_contiguous <damo22>vm_allocate_contiguous already wires memory that is requested right? <youpi>but possibly other memory than the ones allocated by dmalloc, is used for dma as well <damo22>yea that is what i put in the XXX comment but i cant see it in the code anywhere yet <damo22>i wonder if usb fails without wire all <damo22>but it would still be needed for / usbs <damo22>is there any advantage from always booting off a ramdisk of sorts? <youpi>linux doesn't see to see any :) <damo22>might solve a lot of these issues <damo22>since the initial dev nodes can be in ram <youpi>we still need all the path from swapping to disk to be wired <damo22>but wouldnt it be more flexible if / was in ram because the disk would not need to exist before /dev <youpi>yes, there were several proposals in the past to do that <damo22>so you could mount your disk elsewhere <youpi>in practice the device_open chain is enough for our current needs <youpi>what would it gain to mount the disk elsewhere? <damo22>so you have non-persistent startup nodes <damo22>less things can go wrong by hacking the translator nodes <damo22>eg, currently you can toast your install if you settrans -fg something/important <youpi>people have lived with that for decades on linux <damo22>yes, but hurd could be better than linux <youpi>sure, the question is how much we put effort on what <youpi>currently we don't even have swap correctly working, we see bogus data here and there <youpi>(and rumpdisk is still not correctly wired completely against swapping, apparently)