IRC channel logs


back to list of logs

<damo22>sorry, starting work now
<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>damo22: control-alt-d
<youpi>see chapter "Kernel Debugger" in gnumach's info page
<damo22>rebuilding with --enable-kdb
<damo22>hmm ext2fs does not show up in show all tasks
<damo22>but rumpdisk does
<damo22>and exec does
<youpi>so ext2fs died
<damo22>looks like it
<damo22>device_init ran way too fast
<damo22>in rumpdisk
<damo22>theres no way it could have probed the disk in that time
<damo22>i should rebuild librump with debugging MACH_PRINT() defined
<youpi>damo22: ah, yes, mmm
<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 think rump_init is failing
<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>rump_init failed anyway
<damo22>thats a mystery to me
<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>i guess i need the error code
<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>gnu_srs: yep, thanks!
<youpi>damo22: what does it use dlopen for?
<damo22>ill check
<youpi>dlopen can't work in that situation since there is no / yet
<damo22> * no dynamic linking supported
<damo22>i think i need to #undef HAVE_DLINFO
<youpi>ah but that's not dlopening another module
<youpi>just reading the symbols
<youpi>that would normally work
<damo22>at least it does this:
<damo22> mainhandle = dlopen(NULL, RTLD_NOW);
<damo22> /* Will be null if statically linked so just return */
<damo22> if (mainhandle == NULL)
<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");
<damo22>maybe it needs that env var
<youpi>put mach_print in panic() ;)
<damo22>i wish
<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>it defines a putchar
<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).
<janneke>rekado: great, thank you
<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>#include <mach.h>
<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> rumpuser_putchar(int c) {
<damo22>+ char s[2] = {0};
<damo22>- putchar(c);
<damo22>+ s[0] = (char)c;
<damo22>+ mach_print(s);
<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> U mach_print
<damo22>yes mach_print works in libmachdev
<damo22>in device_init()
<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
<youpi>but it's just efficient
<damo22>rumpuser init failed
<damo22>i got dprintf to work
***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>ah, it tries to open it?
<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
<youpi>very possibly
<damo22>doesnt look like pci probed
<damo22>but rump booted
<youpi>yay :)
<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>yes you can
<youpi>just define the variable
<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?
<janneke>rekado: makes for an interesting read with an unexpected persona :-/
<rekado>oh, the 2013 version of rekado!
<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
<janneke>oh, that would be good
<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?
<rekado>no, do you have notes?
<janneke>we're pretty sure that `kill -SIGNAL -1' does not work on our Hurd
<rekado>that’s what I remember
<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...
<rekado>gotta go
<janneke>i'm not sure if the isolation isn't a separate thing? i have forward-ported phant0mas' patch
<janneke>okay, ttyl
<pkill9>what benefits could the Hurd potentially provide for desktop systems?
<janneke>rekado: (i'll ping you later if necessary) here's my latest isolation forward port:
<janneke>pkill9: did you read the `Why bother' section in our latest guix blog? --
<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
<pkill9>plus potentially more stable
<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>ohh this looks great
<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
<pkill9>probably pointless though
<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 :)
<gnu_srs>youpi: BTW: Did you (or somebody else) look into the work by Flávio Cruz about an improved mig: