Date: Thu, 26 Oct 1995 23:41:37 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: msmith@atrad.adelaide.edu.au (Michael Smith) Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br, hackers@FreeBSD.ORG Subject: Re: boot disk.... Message-ID: <199510270641.XAA01050@ref.tfs.com> In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Terry Lambert stands accused of saying: > > Define "work". 8-). > > If I have a disk that claims to be 2000/10/17, and I rewrite it to > 1000/20/17, will the BIOS make the right calculations. It would appear not 8( > > Here are some scribbles wrt. what I'm trying to work out... > > Bootmanager (MBR) looks up first sector of FreeBSD slice. > Have to assume (for now) that it knows how to reach beyond the 1024 cyl. > mark. > > Stage 0 bootstrap (first sector of FreeBSD slice) reads Stage 1 bootstrap > from next N sectors of FreeBSD slice. Uses same technique as the MBR code > to reach beyond 1024 cyls. > > Stage 1 boostrap (lives in first track(s) of FreeBSD slice) (code that > currently gives the Boot: prompt) should search all FreeBSD slices > and partitions looking for an 'a' filesystem containing a file called > 'boot2' (or whatever - it's the stage 2 bootstrap code). > This should be read in (version checks? checksums? fallbacks?) and called. > (Still in real mode) > > Stage 2 boostrap runs in real mode under the BIOS. It should provide > facilities to select the root filesystem and kernel. It should be able > to read the device configuration out of the kernel, and thus inherit > the functionality of userconfig(). It should perform MBR fixup to > guarantee that the absolute offset field in the MBR matches the c/h/s > values for the slice under the BIOS geometry. It should also be buildable > as a DOS program, to allow it to work with Ontrack's Disk Mangler. The > ability to provide the correct major/minor numbers to the kernel > (automatic detection of the wd/hd/sd stuff in the current idiom) would > follow as a matter of course. > major/minor numbers etc. will GO AWAY over the new year The only valid way of specifying a device will be BY NAME this goes for ALL instances EVERYWHERE. Internal to the kernel or External to it. the more ambitious aspect is: dev_t will become a (vnode_t *) it will hold a reference to the vnode you should never fill out a dev_t without incrementing the reference count on the vnode.. (otherwise how can you be sure the device isn't going to go away?) I'm planning on spending the entire of My summer vacation in Australia doing this. (4 weeks minus 4 hours a day swimming etc.) a 'translation scheme' in the startup code will initially translate a code number (e.g. dev_t) to a name. (along with AF_INET being redefined as "inet" not 2.. (how else can you add protcols dynamically?) julian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510270641.XAA01050>