Aw:  Re: Re: [discuss] Kernel and rootfs tinkering

Sat, 27 Jul 2024 10:21:47 -0700 

Hi Bryce, that would be awesome, if you just look into: https://www.illumos.org/projects There is so much for your taste that you be overwhelmed by the things that are pending in 
all areas and due to capacity and knowledge are more in "bug fixing" mode than anything else :-) graphicsdrm, illumos-gate, OpenIndiana you can select depending on your 
taste .. and yes, the arm64 approaches had more an experimental approach with lots and lots of "custom" workarounds (don't want to call them "hacks" :-)) Have 
you installed one of the illumos based dirtros on baremetal (or running in a VM)? .. then you will instantly find out what is missing .. because you will be joining from an 
operating system that has basically support for everything .. Btw. Toasterson (nick) is one of the maintainers of OI, nice guy, very helpful and he arranged some co-working 
sessions to tackle the most "urgent" topics. Cheers Iggi Bryce < [email protected] > schrieb am 27. Juli 2024 um 18:58: Hi, Iggi: I certainly would not mind 
contributing wherever I could. I've been reading through the source for the bootloader, if there are any issues that need to be addressed id love to see if I could help. I'd like 
to port Illumos because, while there do exist several ports to arm64, they are all incomplete or don't work for some people. id like to try fixing this. If there's anything that 
I could contribute I'd love to know. On Sat, Jul 27, 2024, 12:09 PM Ignacio Soriano Hernandez via illumos-discuss < [email protected] > wrote: 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 < [email protected] > 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 < [email protected] > wrote: On Fri, 26 Jul 2024 at 10:49, Bryce < [email protected] > 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/T0d8bd09ba88fa337-M9c78097aa3e6a825ef077f94
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription

Reply via email to