Wow, thanks Joshua 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 on arm64 hopefully then aarch and maybe risc v. (yes, I know it's a lot of work, but I enjoy tinkering in assembly and id like to help the community).
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. 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. 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. On Fri, Jul 26, 2024, 2:26 PM Joshua M. Clulow via illumos-discuss < discuss@lists.illumos.org> wrote: > On Fri, 26 Jul 2024 at 10:49, Bryce <678...@gmail.com> wrote: > > I see. So the third stage bootloader loads the kernel into memory, as > well as the boot_archive, informs the kernel where the archive is (in > memory), then the kernel uses the drivers and such in the programs to load > the root and execute /sbin/init? > > > > I checked the filelist document in > https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/boot/filelist/i386/filelist.ramdisk > and didn't see an /init, do does that mean that whatever the kernel does at > that time is completely controlled by the drivers (as I would expect)? > > There are two distinct styles of boot archive: > > (a) Archive style; e.g., CPIO. Essentially a cache of files from > the real root file system, kept in sync by bootadm(8). This > cache only needs to contain: > > - kernel modules required to locate and mount the root > file system from whichever devices house it > > - any data files (e.g., path_to_inst(5) and system(5) and > so on) that are needed before the root file system is > mounted > > (b) Ramdisk style; i.e., a ufs(4FS) image. This is an entire > root file system, made available to the kernel by the boot > loader. There are a minimal set of routines in the base > kernel that can pick files out of a UFS image like they can > for a CPIO archive, before the file system is actually > mounted. > > In addition to the kernel ("unix") and the boot archive (described > above) the boot loader provides either or both of a command line > string, and/or an environment (a list of string key-value pairs). > In this environment, we provide some additional properties that tell > the kernel which file system driver to use and how to locate the > file system (e.g., a /devices path to the disk, or some information > about the network for NFS root, etc). > > In the archive case, the loader must provide enough detail that when > the kernel calls vfs_mountroot(), we can locate and mount the root > file system. Modules and data needed before that point come from > the archive, and after that point, come from the newly mounted file > system. The init process is started _after_ that, so we don't need > to include it in the archive. > > In the ramdisk case, the kernel first treats the UFS image as an > archive up until vfs_mountroot(), when it "mounts" the UFS image > in-place in RAM and things proceed normally as if it were accessing > a physical disk -- with the obvious caveat that changes will be > destroyed on reboot. This is how install images work today; they > boot from an ISO or a USB image into this kind of ramdisk and then > load other software by finding and mounting the boot device later > from usermode. It's also how SmartOS works. > > At Oxide, we've got a prototype for a new kind of booting, using a > combination of a CPIO boot archive that contains drivers for disks > and the ZFS modules, and then having the kernel load a ramdisk image > from a slice on an NVMe device into RAM. To do this, I had to add > new hooks into the main() routine of the kernel just prior to > vfs_mountroot() so that we could inject some custom behaviour from a > separate kernel module we build. It's designed to be customisable > without changing the base kernel source, but also not quite ready to > upstream to mainline illumos -- though I'm keen to get it up there > eventually! > > If you want to get started with a minimal boot-to-ramdisk system, I > would probably look at SmartOS, as that's what it is! It uses the > UFS ramdisk approach today, and that ramdisk is able to locate other > resources on physical disks as needed, etc. We also have some tools > the allow building images automatically from templates: > > https://github.com/illumos/image-builder > > There is no documentation there right now, but I have some examples > of how to use it up here: > > https://github.com/jclulow/omnios-image-builder > > I have, in my home directory, other templates I'm yet to add there > which can construct a custom OmniOS-based ramdisk image that you can > add software and custom boot-time behaviour to. If you want me to > throw that up in there, let me know. > > Happy to answer any questions, as I know this is a lot to take in! > It would help to have more concrete specifics about how you're > looking to operate the system you're building, what software you're > hoping to include, how autonomous it should be, how you're hoping to > update it, etc. > > Cheers. > > -- > Joshua M. Clulow > http://blog.sysmgr.org ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tc9bfa679c7294ee7-M28510cfa46cbc7fce1c702a4 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
