On Fri, 26 Jul 2024 at 11:57, Bryce <[email protected]> wrote:
> that makes a lot of sense. I'm trying to build a monolithic illumos kernel
> that includes its own root file system. I want to do this because I see that
> illumos is really only established on x86 with a weak standing in SPARC, and
> I'd like to try and port Illumos to other arch's. I'd like to get a minimal
> image working on x86 first though, and troubleshoot my way from there
I do think that's a good place to start, to get familiar with building
OS bits and assembling and configuring them, etc. Indeed, most people
are using i86pc (x86) these days, so that's a good place to experiment
and it's easy enough to do in a VM on most systems.
> so, the bootloader passes a command line string and perhaps an environment
> listing (which I assume is also a string?) to the kerbel, does it pass these
> as pointers? If so, are they pushed onto the stack? and if that is so, then
> does the bootloader load the kernel and set up SS and BP in the process?
>
> speaking of which, does the loader switch into protected mode before loading
> the kerbel (I assume so, as to load a ufs/cpio archive with drivers I'd
> assume you'd need more than a meg of memory.
Our boot loader is actually a Multiboot2 loader:
https://www.gnu.org/software/grub/manual/multiboot2/multiboot.html
The specification outlines a partially defined expected machine state,
and the layout of control structures that allow us to pass arguments
and modules to the kernel. On i86pc, we then have "dboot", which is
our Multiboot2 entrypoint and which handles getting the system the
rest of the way up from that predefined state. The dboot object is
built and stuffed into "unix" along with the rest of the core of the
kernel.
You don't strictly need to use our boot loader, though. Folks in the
SmartOS community make extensive use of iPXE, from their fork:
https://github.com/tritonDataCenter/ipxe
At Oxide, we're actually working on a new architecture, "oxide", that
sits as a peer alongside the existing "i86pc". In our world, there is
no BIOS/EFI firmware at all, just a ROM on the motherboard. We put
our kernel and CPIO archive into the ROM, and then the kernel itself
loads the root file system from an NVMe disk once it's running. In
this model, we've had to fold all the things a BIOS would do to get us
to the boot loader, and then what the boot loader would have done,
into our single ROM image. None of that is as yet available in
illumos-gate, but we're building it to be upstream-ready in the long
term.
https://github.com/oxidecomputer/illumos-gate/tree/stlouis
> Also, can the loader be configured to load the kernel from a known address on
> disk, instead of from a file system? if not that's fine, I could patch the
> source to support that. I ask because I used legacy grub a long time ago, and
> I'm pretty sure it doesn't have that feature, but idk how illumos has patched
> their grub 0.98.
We actually don't use our legacy GRUB anymore. It hasn't been deleted
from the source tree, but it will eventually be when someone finds
time to do that gracefully. Our current boot loader is in the tree
under "usr/src/boot", and is one we imported from FreeBSD. I don't
believe that loader can read directly from a disk slice, but it does
have support for several file systems including pcfs (aka FAT), hsfs
(aka ISO), UFS, ZFS, etc.
> I'll definitely refer to omnios to see how the big guys do it, but it's not
> quite what I'm looking for.
>
> thank you for offering the templates, but I was looking for a slightly lower
> level modification.
Alright! You're always welcome to assemble the pieces yourself, of
course. The templates are just a sequence of steps for doing that, so
even if you don't use them, it might help from time to time to refer
to what they're doing. The packaging system (which the image builder
will drive) is also responsible for assembling certain data files like
"/etc/driver_aliases" that define which drivers get attached to which
hardware, etc. I expect Peter has reworked at least some of that in
his "minimal viable illumos" project, so that may be work looking at
also to see what's required in place to boot.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
------------------------------------------
illumos: illumos-discuss
Permalink:
https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-Me6bd44b7d0839e1c58ed16f4
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
