From owner-freebsd-hackers Fri May 10 10: 3:34 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from gull.prod.itd.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by hub.freebsd.org (Postfix) with ESMTP id 0B29337B40A for ; Fri, 10 May 2002 10:03:27 -0700 (PDT) Received: from pool0211.cvx22-bradley.dialup.earthlink.net ([209.179.198.211] helo=mindspring.com) by gull.prod.itd.earthlink.net with esmtp (Exim 3.33 #2) id 176Dne-0002iY-00; Fri, 10 May 2002 10:03:23 -0700 Message-ID: <3CDBFD3C.37C51A8E@mindspring.com> Date: Fri, 10 May 2002 10:02:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Julian Elischer Cc: Gordon Tetlow , Michael Smith , hackers@freebsd.org Subject: Re: nextboot loader diff References: <3CDBDB72.FC3C9CB7@elischer.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer wrote: > I wrote the original 'nextboot to use block 1 (ususally unused) > to avoid under all circumstances writing into the filesystem. > > Also, part of the weakness of the current system is that it presumes you know > which IS the root filesystem. The original nextboot took as part of the > information it loaded from block 1 (assumuing it checked out as a boot-spec > block) the partition to use as the root. If the root partition is totally hosed > you may not be able to READ /boot/{anything}. The original nextboot > was really a local hack to fix a local problem, but I was thinking of making it > more > 'acceptable' to the world as a whole by making it look for a DOS partition of > some type, and {length 1,location 1} before loading information. > > I deliberatly kept this information outside the filesystem. If you always write the blocks back to where you got them, there's no real difference for a small file. Adjacent disk blocks are adjacent disk blocks, and it doesn't matter how they are located (hard coded constant value, or math on hard coded constant values). In general, what you want is a read-only boot FS that has only the boot code and the loader stuff in it. The FORTH fwrite code (if Jon Mini and James really did use my code for part of it) ignores readability/writeability not enforced by hardware. The *only* think you want to be writing is those adjacent blocks, which are associated with a file more as a convenience than anything else. The "nextboot" command itself needs to blow the file contents directly; unfortunately, now that we do not have two devices that reference the disk (one for mounting, one for blowing file contents directly, as in this case), this means mounting the boot FS read/write, blowing the file contents, and then mounting it read-only again. The (length l, location l) idea is the same thing LILO does; it is much better to simply compute the location off constant FS information, which is going to be there (and constant) anyway. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message