Date: Tue, 24 Jan 95 9:33:31 MST From: terry@cs.weber.edu (Terry Lambert) To: bde@zeta.org.au (Bruce Evans) Cc: julian@tfs.com, peter@bonkers.taronga.com, hackers@FreeBSD.org, mmead@goof.com Subject: Re: writing bootcode; need a method Message-ID: <9501241633.AA12193@cs.weber.edu> In-Reply-To: <199501240732.SAA12857@godzilla.zeta.org.au> from "Bruce Evans" at Jan 24, 95 06:32:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> I usually call 1) and 3) the first stage boot. We need a stage after > that soon. I want it to be in /kernel0. I used to agree with this. The implication is that the boot manager smarts are in the third stage boot. Now I am almost convinced of the SVR4 /stand approach, especially now that someone has modloading the /usr VFS! > 6) BSD bad144 table at the end of what the disklabel and/or the drivers > say is the end of the disk (the wrong place). I want to reiterate: wrong place. This table really wants to be either prior to or following slice 'a'. For a system with local swap, following slice 'a' makes more sense, since you can enlarge the table by stealing swap, on the theory that it's better to be able to load the kernel than it is to be able to make user processes inactive. For a system without local swap, or swap on other devices, it's irrelevent, since the table will end up being fixed size in either of the locations, with no chance to expand without a full backup/newfs/restore. > On "i386" systems there are also the DOSpartitions, which can be laid > out as something between a ternary and a quaternary tree and can have > slightly complicated overlaps with each other and very complicated/ > incoherent overlaps with the BSD partitions, especially on > misconfigured systems. [Picture omitted due to lack of time, space > and drawing capabilities.] It's tempting to use these, since Linux does, but this really messes up other architectures, since they are unlikely to start their disks with a DOS boot + partition table. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9501241633.AA12193>