<youpi>damo22: when rump doesn't have a bootstrap port it should just not call fsys_startup <youpi>see how libdiskfs does it in diskfs_startup_diskfs ***Server sets mode: +nt
***gianluca is now known as Guest73508
<damo22>it entered the trivfs server loop and hung <damo22>how do i drop into db> shell from userspace? <damo22>is there a key sequence i can break ? <youpi>see chapter "Kernel Debugger" in gnumach's info page <damo22>hmm ext2fs does not show up in show all tasks <damo22>theres no way it could have probed the disk in that time <damo22>i should rebuild librump with debugging MACH_PRINT() defined <youpi>either you have a way to wait for rump to complete probing <youpi>or we make libstoreio try to wait a bit when device_open gets ENODEV <damo22>well device_init does not return until rump has finished probing, i think <damo22>because rump_init() blocks afaik <damo22>i assume libstoreio does not try to call device_open until device_init() has returned right? <youpi>? libstoreio doesn't have a device_init <youpi>libstoreio (inside ext2fs) will will call device_open as soon as ext2fs is resumed <youpi>so you need to resume the ext2fs task after device_init is finished <damo22>i recompiled rump with debugging in pci-userspace <damo22>nothing printed out in rump_init <damo22>it seems to already resume the ext2fs task after device_init returns <damo22>but rump_init returns an error but mach_prints nothing <damo22> /usr/bin/ld: /usr/lib/librumpuser_pic.a(rumpuser_dl.pico): in function `rumpuser_dl_bootstrap': <damo22>(.text+0xb9): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking <gnu_srs>youpi: mahler is up again. Please confirm <damo22>could this be a problem for rumpdisk.static? <youpi>damo22: what does it use dlopen for? <youpi>dlopen can't work in that situation since there is no / yet <damo22>i think i need to #undef HAVE_DLINFO <youpi>ah but that's not dlopening another module <damo22> mainhandle = dlopen(NULL, RTLD_NOW); <damo22> /* Will be null if statically linked so just return */ <youpi>but here since it's linked statically it'll return NULL, which is expected <damo22>it handles it quite nicely i think <damo22> if (rumpuser_getparam(RUMPUSER_PARAM_HOSTNAME, <damo22> hostname, MAXHOSTNAMELEN) != 0) { <damo22> panic("mandatory hypervisor configuration (HOSTNAME) missing"); <youpi>put mach_print in panic() ;) <damo22>rump takes 40 minutes to rebuild though <youpi>you can still let that boot while doing other stuff, you'll very probably want it anyway <damo22>i can override the debug in rumpdisk! <damo22>#error The rump/rumpuser.h interface is not for non-kernel consumers <damo22>ok i hacked rumpuser to putchar with mach_print <rekado_>janneke: I pushed four commits to wip-hurd-vm; two for NFS support (which I must have forgotten to push last time), and two for netdde. ***rekado_ is now known as rekado
<rekado>janneke: I just pushed four commits to wip-hurd-vm; two for NFS support (which I must have forgotten to push last time), and two for netdde. <rekado>I made a mistake with the order of cherry-picked NFS commits, but I didn’t want to delete and re-push the branch (lest I accidentally delete some of your work) <damo22>youpi: does <mach.h> suffice for mach_print() ? <rekado>janneke: 640ec8ac3823dd2d2e0565497f8a362f88b43274 (enabling NFS support in the hurd package) should come after 4c5a3e1ae7005c81f271744f77a0c83130d08fa8 (adding libtirpc/hurd). <youpi>damo22: grep says it's in mach/mach_traps.h <janneke>rekado: i'm saving this information; we should be consolidate wip-hurd-vm about now start another merge IMO; so this is perfect timing! <damo22>int main (int argc, char **argv) { mach_print("YEP\n"); return 0; } <damo22>This works, but my rump_init doesnt <youpi>damo22: what is the issue? at compile time? at link time? at execution time? <damo22>at runtime it doesnt print anything with rumpuser_dprintf <damo22>even though i changed the function as above <youpi>does nm show that the .o file references mach_print? <youpi>does a mach_print in your translator file, vs a mach_print at the head of the rump initialization function vs a rumpuser_dprintf at the head of the rump initialization function work? <damo22>nm librumpuser_pic.a |grep mach_print <damo22>yes mach_print works in libmachdev <damo22>so it works the line before it calls rump_init() <damo22>and in rump_init() i put rumpuser_dprintf ("hello") at the top of the function <youpi>also try to put mach_print there <youpi>and if that works but rumpuser_dprintf not, put mach_prints all along the call path between there and rumpuser_putchar <youpi>I'm really surprised how much people are not used to just do that <youpi>it's like a big hammerish way of debugging ***lp is now known as Guest74463
***vup2 is now known as vup
<damo22>could be something dumb like a bash env var is not defined <rekado>I’m currently working on updating the drivers in netdde and noticed that virtio_net is blacklisted because “These are not usedful” <rekado>is that because the Hurd doesn’t yet have an implementation of virtio? <damo22>youpi: i think its failing due to /dev/urandom not being present on the system <youpi>that's deemed to fail indeed <damo22>im going to comment out the check that makes it hard fail <damo22>maybe we dont even need a PRNG for what we are doing <damo22>so the question is, why would it find zero pci devices <youpi>possibly libpciaccess doesn't use the x86 method? <damo22>maybe so, i'll look into it tomorrow after work <damo22>correct, i think libpciaccess does not fall back to x86 unless its name is called "pci-arbiter" <damo22>how do i fake the rumpdisk netfs_server_name <damo22>can i just define it in rumpdisk? <youpi>it'll override the weak definition in libpciaccess <damo22>thats wierd, it made no difference <damo22>do i need to declare it extern as well? <rekado>back then I had just read “virtio: Towards a De-Facto Standard For Virtual I/O Devices” and the v0.9.5 draft of the Virtio PCI Card Specification. <rekado>IIRC the result of that discussion was that I had no idea how to approach PCI arbitration and gave up on virtio work. <rekado>I wonder if damo22’s work might help me overcome this obstacle <rekado>janneke: while playing around with NFS I created variants of rcpbind and libnsl; I think it would be best not to create too many hurd-specific variants, though. Is it fine to update packages with Hurd patches on wip-hurd-vm or would you like to have this happen on a separate branch to avoid churn? <janneke>rekado: i'd vote to keep our efforts in one place right now and update wip-hurd-vm <janneke>the wish to consolidate and merge with core-updates has mainly todo with the experiments; solid patches are /much/ less of a problem, imo <rekado>janneke: if you aren’t already working on this I’d like to look into the guix-daemon problem that prevents us from killing child processes. <janneke>rekado: i am not looking into that right now, but have you seen what civodul and i found out about that earlier? <janneke>we're pretty sure that `kill -SIGNAL -1' does not work on our Hurd <janneke>ah, okay -- it looks like a glibc thing...there's only the mail archive...wait <rekado>I wondered if we could work around it in the daemon. <rekado>(just so we can start building things in isolation) <rekado>another project that I wanted to work on is to add Guile bindings for translators. There already is a Common Lisp implementation in incubator.git that could serve as a guide. <rekado>having a Guile API for translators would make them usable for Guix and the Shepherd, which could be handy. <janneke>but yeah, we could look if we could work around that in the daemon... <janneke>i'm not sure if the isolation isn't a separate thing? i have forward-ported phant0mas' patch <pkill9>what benefits could the Hurd potentially provide for desktop systems? <pkill9>yea, what other potential benefits could there be other than more elegant containerisation and bootstrapability? *janneke is not entirely sure what "a desktop system is", i have been told for > 25y that my computer is not a "desktop" system <pkill9>and the translators are pretty neat <janneke>one personal interest would be formal verification of communication protocols between servers, but i'm not entirely sure if the hurd applies <janneke>also, i imagine prototyping/having servers in guile <pkill9>prototyping servers? (whatever they're called that the Hurd uses) <pkill9>hopefully that could mean rapid development of support for all sorts of things <janneke>yes, and i like a system built with user freedom in mind <pkill9>could it simplify the 'plumbing' in modern linux distros, e.g. DBus, polkit, etc? <pkill9>well, manage or reduce the complexity of it all <pkill9>like how guix manages the complexity of dependency hell <janneke>i have no idea...i'm pretty new to the hurd; i wrote ported a tiny bit of the mes c library to the hurd about a year ago, and have been creating a vm the past two months -- i'm asking all kinds of faq here :-) <janneke>(i installed or tried installing the hurd some 20y ago, but didn't do anything with it) <janneke>now it seems to be picking up some steam, which is amazing <gnu_srs>janneke: Hurd has been progressing steadily in recent years. That you from the Guix side have a renewed interest is all good for the Hurd progress :) <janneke>gnu_srs: yes, that's evident; i have been very impressed with the debian images, and thankful that <pkill9>is there a translator for torrents? <pkill9>being able to browse through many types of data with ranger/lf <pkill9>it would be neat to browse through nested torrents <pkill9>e.g. a torrent file containing torrent files <gnu_srs>janneke: Too bad I have not been allowed to publish my hurd-cross project to Savannah yet :( Eventually it will be there soon. <gnu_srs>I think you can find some ideas from my work and I would appreciate help and feedback from you Guix guys too :)