Date: Fri, 10 May 2002 10:02:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Julian Elischer <julian@elischer.org> Cc: Gordon Tetlow <gordont@gnf.org>, Michael Smith <msmith@mass.dis.org>, hackers@freebsd.org Subject: Re: nextboot loader diff Message-ID: <3CDBFD3C.37C51A8E@mindspring.com> References: <Pine.LNX.4.44.0205091245420.558-100000@smtp.gnf.org> <3CDBDB72.FC3C9CB7@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CDBFD3C.37C51A8E>