00:08:24 <richlowe> tsoome_: so we take the virtual address to start allocating from in early boot (do_bsys*) from dboot in `bi_next_vaddr`, which appears to figure it out on its own.  But we seem like we _probably_ used to assume that early boot allocated within MISC_VA_BASE,MISC_VA_SIZE (the range we `boot_mapin`)
00:08:58 <richlowe> do you know if I'm correct about MISC_VA? Do you know why we still mapin MISC_VA* (modulo unmapped pages), but that seems otherwise unspecial? do you know why, when we _do_ boot
00:09:15 <richlowe> _mapin we take `size` from `availrmem` but only actually _take_ those pages which are mapped
00:10:57 <richlowe> I find myself in the position where the x86 port maps it in (but doesn't seem to treat it as special to actually have a reason for that), and the arm64 port treats it specially for early allocations (mostly), but doesn't map boot memory that way 
00:11:11 <richlowe> I don't know if correct is neither or both :)
00:16:22 <tsoome_> so those constants are referring to before kernel text. I guess thats safe area because early boot allocations do happen from after kernel text+data+bss+modules and do_bsys is assuming everything after kernel + loaded bits is unused.
00:19:11 <richlowe> so it happens that the next free va that dboot hands to unix is within the MISC_VA range?
00:19:54 <richlowe> because otherwise how do we take over the mapping, if it's not in the range we `boot_mapin`?
07:30:39 <gitomat> [illumos-gate] 17623 vioscsi: panic during detach -- Hans Rosenfeld <rosenfeld⊙gho>
16:01:11 <jbk> hrm..
16:01:34 <jbk> it does seem like we could improve how installboot works (at least for EFI systems)
16:02:02 <jbk> e.g. write out bootloaders to partition w/ a temp name and rename
16:02:29 <jbk> (if the write fails for some reason, it currently leaves the disk unbootable)
16:03:37 <jbk> also, perror() (err()/warn() and the like would be better.. esp for anyone using installboot from a script or such since it'll make it clearer the source of the error
16:04:08 <tsoome_> that sounds nice.
16:04:55 <jbk> (and using the *at() interfaces would simplify a lot of the code -- open /boot and the mount point and can do read()/write()/stat() relative to there
16:57:45 <sommerfeld> jbk: assuming there's enough extra space on the partition for more than one copy...
17:01:23 <jbk> the zpool create -B is 256MiB, the loader binary is a bit under 600KiB
17:03:52 <jbk> and there at least, you still have the old version
17:04:07 <jbk> (or we could add an overwrite for such situations)
17:08:25 <jbk> also, installboot seems inconsistent on using stdout vs stderr for errors...
17:09:33 <jbk> (i've been fighting it for our stuff to install a few extra EFI binaries for diagnostic/troubleshooting purposes, and hitting all of this stuff as all of the assumptions of the default system being a BIOS booted system makes it more complicated than you would hope)
17:10:51 <jbk> it might be worth making it easier in general if other distros wanted to do something similar (e.g. add memtest or the UEFI shell or something else)
17:23:40 <gitomat> [illumos-gate] 17684 bhyve/virtio-scsi: various small improvements -- Hans Rosenfeld <rosenfeld⊙gho>
17:23:40 <gitomat> [illumos-gate] 17685 bhyve/virtio-scsi: support for multiple targets -- Hans Rosenfeld <rosenfeld⊙gho>
17:23:40 <gitomat> [illumos-gate] 17686 bhyve/virtio-scsi: implement task management functions -- Hans Rosenfeld <rosenfeld⊙gho>
17:23:40 <gitomat> [illumos-gate] 17620 bhyve/virtio-scsi: support multiple backends -- Hans Rosenfeld <rosenfeld⊙gho>
17:23:40 <gitomat> [illumos-gate] 17619 bhyve/virtio-scsi: implement USCSI(4i) backend -- Hans Rosenfeld <rosenfeld⊙gho>
17:23:41 <gitomat> [illumos-gate] 17776 bhyve/virtio-scsi: make all I/O processing parameters configurable -- Hans Rosenfeld <rosenfeld⊙gho>