Date: Thu, 06 May 1999 15:16:29 -0700 From: Mike Smith <mike@smith.net.au> To: Zhihui Zhang <zzhang@cs.binghamton.edu> Cc: freebsd-hackers@freeBSD.ORG Subject: Re: Boot blocks Questions (was: superblocks in FFS) Message-ID: <199905062216.PAA01771@dingo.cdrom.com> In-Reply-To: Your message of "Thu, 06 May 1999 17:58:50 EDT." <Pine.GSO.3.96.990506174822.16113B-100000@sol.cs.binghamton.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > I have some questions regarding the new boot blocks used in FreeBSD 3.1: > > (1) Can these boot blocks (I assume that they can occupy at most 15 > sectors because we need one sector for the disklabel in the first 16 > sectors. BBSIZE == 8192) reside in a filesystem other than the root file > system? They don't reside in the root filesystem, they reside at the beginning of the slice. > (2) Is the boot block code smart enough to find the kernel or loader > (/boot/loader) in a different FreeBSD slice (Suppose we have more than one > FreeBSD slice on the same machine and the root filesystem happens to be on > a different slice. I believe that the slice where the boot block code is > used must be set to be active). Yes. > (3) It seems to me that the loader (/boot/loader) can set up some kernerl > configuration parameters (e.g. nmbcluster) that override what you have in > the kernel. Can anyone describe a little for me on how this is achieved? The loader passes its variable space into the kernel in environment format. There are kernel functions for extracting variables out of this environment that are used to provide seed values for constants that need to be established before the system is running. I have almost completely eliminated param.c in my working tree, and established a couple of new macros for dealing with kernel tunable values that should make this process even easier. The process is pretty simple; you create a very early sysinit bracket and a tiny init function for every tunable. Each init function calls the kernel environment code to see if there is an overried, and otherwise sets the tunable to the compile-time default. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905062216.PAA01771>