IRC channel logs


back to list of logs

***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>so that assertion is wrong
<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>ah i found a bug in the logic
<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>youpi: im not sure where to register the notification, i get this
<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>in machdev
<damo22>this is what i have so far
<damo22>root@zamhurd:~# reboot-hurd ...
<damo22>startup: notifying ext2fs part:2:device:/dev/wd0 of reboot..
<damo22>so it needs to notify ext2fs..
<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>well, you really should do
<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>see libdiskfs
<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
<damo22>ok thanks
<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>i'll have to find out
<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
<damo22>i think so
<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
<damo22>ah yes
<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
<damo22>interesting, gets complex
<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?
<youpi>we won't
<damo22>i thought so
<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>lots of work still to be done!
<youpi>not that much actually
<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
<damo22>bed time
<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