Aw:  Re: [discuss] Kernel and rootfs tinkering

Sat, 27 Jul 2024 09:08:14 -0700 

Hi Bryce, let me first complain as I cannot help you with your request. Reading this posting I just ask myself, why is this 
the next try to make something where illumos and several distros based on it still lack core capabilities (see the driver 
support, power management, graphics subsystem, etc, etc.) there even have been several proof of concepts with regards to 
having an illumos based distro on arm64 (yes, several projects made it up to prompt and some core capabilities) while someone 
with that deep knowledge would be a huge asset to get some things done to close some gaps? And don't get me wrong please, I 
like that there are projects one wants and has to do because it THAT what gathers your interest :-) So if you like to get into 
the core core there are lots of areas where someone knowledgeable like you could deliver so much value to the whole community 
. Thanks for your passion and motiviation and welcome in the rabbithole :-) Cheers from Germany Iggi Bryce 
<678...@gmail.com> schrieb am 26. Juli 2024 um 20:59: 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-Ma01a51d0c7fe2e4bc5c02ceb Delivery options: 
https://illumos.topicbox.com/groups/discuss/subscription illumos / illumos-discuss / see discussions + participants + delivery 
options Permalink
------------------------------------------
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/Ta3de79b601a98cac-M322da0570ac087beba9e72dc
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to