***random-nickname is now known as random-nick
***Server sets mode: +nt
<damo22>WARNING: ds_device_open: not master device <damo22>it keeps printing that when i bootstrap rump <damo22>i think the bootstrap port is not the same as the master device port? <damo22>when i make it just print a warning instead of fail, it works <damo22>fixed, but it needs startup notification <damo22>youpi: where do i call arrange_shutdown_notification() so that _SERVERS_STARTUP exists? <damo22>can i call near the end of machdev_trivfs_init() ? <damo22> fs Hurd server bootstrap: ext2fs[part:2:device:/dev/wd0] exec startup proc auth. <damo22>i cant seem to test reboot because it gets stuck at loading netdde and ssh <damo22>it seems to go to init 6 instead of init 0 <gnu_srs>youpi: Putting mach_print statements in proc/wait.c causes a reboot loop due to proc server crashing?? <damo22>gnu_srs: i had trouble with rump because i was printing to the console before it was open, but i think proc is way after bootstrap <youpi>damo22: init 6 is the reboot initlevel, so that's expected <youpi>gnu_srs: really, there is no reason for mach_print to fail, it's just a system call <youpi>(and from the point of view of userland that's completely unrelated to the mach console) <youpi>damo22: to test for reboot without being hit by userland bugs, perhaps try reboot-hurd instead <youpi>that'll skip the daemon etc. part, which might be stuck for completely unrelated reasons <youpi>for knowing when you can call the startup_notification, IIRC I wrote something some days ago in irc about an fsys call that ext2fs can forward to let your bootstrap process know when the FS is ready <youpi>perhaps we'd need to add in it some port parameter for pre-FS bootstrap translators to get a port to the / filesystem <youpi>we'll need that for pci-arbiter to attach itself to /servers/bus/pci anyway <damo22>can i arrange for the shutdown notification to be handled by calling it in trivfs_S_fsys_startup? <damo22>startup: notifying ext2fs part:2:device:/dev/wd0 of reboot.. <damo22>and ext2fs needs to forward that notification back to libmachdev <youpi>? startup should be able to notify machdev itself <youpi>did you check that file_name_lookup in arrange_shutdown_notification did work, for a start? <youpi>“if we fail for some reason, just silently give up. No big deal.” <youpi>there's actually a big deal with the rump server <youpi>the disk drivers have to flush their data <youpi>it does print an error in that case <youpi>and anyway, when debugging, do put prints to make sure that things you wrote are actually working the way you wanted them to <youpi>if you make any kind of "nah, that can't be it" assumption, you'll have a risk that yes it is it <damo22>i did put prints before to test but i removed them before sending in patches <youpi>btw, you also need to mark the translator as important with proc_mark_important() <youpi>again, see how diskfs does it <youpi>other translators don't need care much about data <youpi>re: about knowing when file_name_lookup will work, see the fsys_startup RPC <youpi>that's what children translators use to notify their parent when they are ready <youpi>rump can use that to know when the / FS is ready <youpi>Mmm, that said I wonder: you are passing a bootstrap port to the / FS, right? <youpi>I wonder how diskfs_start_bootstrap() would be getting called, then <youpi>since it seems libdiskfs either calls fsys_startup, or diskfs_start_bootstrap, and not both <damo22>hmm i dont know, i remember putting prints in trivfs_S_fsys_startup and never seeing it <youpi>so that's "why" you get a boot to succeed <youpi>the / FS is not actually seeing your bootstrap port <youpi>but then I wonder how it manages to contact your rump translator? <damo22>the rump translator is called as the bootstrap process <youpi>yes, but how does the / FS knows it has to contact that instead of gnumach? <youpi>remember that since I don't actually work on this part, I don't even remember what I told you a week ago <damo22>it implements device, and all calls to devices go through rump <youpi>but how does the FS know the master device port is rump, and not the kernel? <youpi>AFAIR, task_set_special_port (server_task, TASK_BOOTSTRAP_PORT, right); is what should be doing it <damo22>yeah i think i override the master device port to be the bootstrap port <youpi>but apparently diskfs_startup_diskfs doesn't get that bootstrap port there <youpi>and that's why you don't get a fsys_startup call <youpi>where did you override this? <damo22>when it asks for the host private port, i give it a different one <damo22>i create a port in the trivfs libmachdev port_bucket <youpi>ok, but that would mean that the / FS bootstrap really is rump <youpi>libdiskfs/boot-start.c: err = fsys_getpriv (bootstrap, &_hurd_host_priv, &_hurd_device_master, <youpi>since that's where it makes its fsys_getpriv call <youpi>I wonder why in diskfs_startup_diskfs it'd go the non-bootstrap way rather than the bootstrap way <youpi>aaaah, that's because it's not the same bootstrap variable <youpi>the bootstrap variable in diskfs_startup_diskfs comes from the ext2fs call, and that comes from the diskfs_initmain() call, which sets it to NULL only when the command line is set <youpi>then I would say that in diskfs_startup_diskfs, when bootstrap == NULL, call task_get_bootstrap_port() to check whether there actually is a bootstrap port <youpi>and then call fsys_startup on it anyway, after doing the diskfs_start_bootstrap <youpi>put another way, rearrange the code, to first handle the bootstrap== NULL case by calling diskfs_start_bootstrap and call task_get_bootstrap_port(), and after that, check for bootstrap != NULL again, and call fsys_stratup etc. <youpi>(but probably not call _diskfs_init_completed(), that'd probably initialize some stuff twice) <youpi>well bootstrapping is always a complex matter <damo22>if rumpdisk crashes for some reason during runtime, how will we recover? <damo22>in that case, why do we need it in userspace? <youpi>(yeah, in diskfs_startup_diskfs you probably want to separate out the bootstrap port passed by ext2fs from the bootstrap port you get from the task_get_bootstrap_port, to know whether you want to call _diskfs_init_completed or not) <youpi>what do you mean by "need it in userspace" ? <damo22>i mean, is there any reason to separate out a driver to a unikernel if it is just as important as the kernel itself not to crash? <youpi>yes, because that's only for / <youpi>for anything else in the system, you can use a different disk and a different disk translator <damo22>im having an issue that i cant very easily mount a second partition from the / rumpdisk driver <youpi>rumpdisk will need to register itself in the / FS to show up there so you can mount from it <damo22>the AHCI controller is hogged by the bootstrap translator, and i cant seem to "address" a second partition <youpi>but for that you need the fsys_startup thing to work so rump knows when it can do that <damo22>im glad you can see light at the end of the tunnel, for me it looks dark <damo22> fs Hurd server bootstrap: ext2fs[part:2:device:/dev/wd0] exec startup <damo22>Arranging shutdown notification for machdev <damo22>WARNING: machdev not registered for shutdown <damo22>so it cannot access _SERVERS_STARTUP <damo22>but at least it is calling fsys_startup now <youpi>damo22: I have added to the wiki a page describing the bootstrap dance <youpi>darnassus seems unreachable at the moment, but you can get it from the savannah wiki ***nckx is now known as AMDinc
***AMDinc is now known as nckx