> yes unix is just another partially relocated module > in > some ways. krtld gets to initialize almost first, so > that > genunix is loaded early and then things in unix can > call > things in genunix. That way very little code has to > be > aware about the unix/genunix split. > > For example, in developing the code for > fakebop.c:_start(), > I had to be careful to not invoke anything from > genunix - > as that doesn't work before krtld gets to run. > > krtld will also then know how to resolve references > in later loaded > modules against the symbols in unix. > Where can I learn more about krtld? For example, this relocation stuff seems very important, but I don't understand it (I guess I don't even have the concept).
> that depends. pre-build 57 krtld was always a > distinct > module. Now it's just linked into unix on x86, but > still a distinct module on sparc. That's what the > #define for _UNIX_KRTLD is about in kobj.c. The > define exists for sparc, but not x86 currently. > Wouldn't it be more modular if krtld were in its own module, rather than built into unix? That's a theoretical argument, I guess, but I am curious about why it has changed when apparently the natural trend is to make the kernel smaller... > I'm not that familiar with how other loadable > modules are found - I've generally worked on lower > level things that are always in unix or genunix. > You can either go read the code (what I'd do), try > google, > or start a new thread with that question. > modload() is the key function that loads a module, > so searching for how/why it's called would be > where I'd start. Thanks for the hint. I'll look into it as soon as my minimal environment starts booting successfully :-) > > The Solaris Internals book, ISBN 0-13-148209-2, may > be helpful for more generic questions like that. I have that book and also its performance tools companion. Just it treats matters in a depth-first fashion (all about the scheduler, all about the processes, all about virtual memory, all about file systems, etc.) when what I need in this first moment is a breadth-first treatment, what are the big boxes, how they interconnect, what happens if I remove one of them, etc. I expect to be able to read it as I get acquainted with the kernel, but it's too difficult right now. However, I appreciate getting recommendations to read specific sections as a complement of hints. > Note -- there is no boot archive *yet* on sparc. > Soon, > but not yet. Sparc relies on OBP to go read the real > disk (or network file server) for files during early > boot. > > For x86, BIOS is a horribly slow way to read disk. > Also sometimes we wind up getting > root from devices which BIOS just can't get to. > Diskless clients are an example. There's no > requirement that the boot archive come from the > same device as the final "/". > OBP behaves for SPARC like the BIOS for x86, right? > Almost. Before every poweroff or reboot a check > is made to see if the boot_archive has gotten out > of date (ie. you may have added a new file system > or device driver). If you remove a device driver > from > the filesystem, I believe that bootadm may also > remove it from the boot archive. If you really > needed that driver, you'll have wrecked your system. > > > You could try that. Here is a now out-of-date blog > entry where someone was doing something similar. > > http://blogs.sun.com/szhou/entry/build_a_minimal_solar > is_image > > It pre-dates dboot and many other changes, so some of > what > he did no longer is necessary and some is just wrong > now. I am trying to figure out what happens now in the boot as main calls vfs_mountroot (usr/src/uts/common/os/main.c:440), which calls rootconf (usr/src/uts/common/fs/vfs.c:805), which calls VFS_MOUNTROOT(usr/src/uts/common/fs/vfs.c:4132) which fails and spits the "cannot mount root path %s" (usr/src/uts/common/fs/vfs.c:4137), where the %s printed on my console is exactly the value of the bootpath property I had set in /boot/solaris/bootenv.rc and in the boot archive (through a bootadm boot-archive -v -r /mnt): '/[EMAIL PROTECTED],0/...'. It's been very difficult to figure it out, as I don't have the slightest idea where the rootvfs gets initialised to its vfs_ops. The vfssw global variable seems to be uninitialised as of its declaration (usr/src/uts/common/fs/vfs.c:3601) and I found no code that initialises it afterwards. I suppose this is past the boot archive file system reading, so I suppose at this stage it might be reading the real disk... Any hints here? This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
