From owner-freebsd-hackers  Thu Oct 26 23:44:02 1995
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id XAA02515
          for hackers-outgoing; Thu, 26 Oct 1995 23:44:02 -0700
Received: from ref.tfs.com (ref.tfs.com [140.145.254.251])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id XAA02510
          for <hackers@FreeBSD.ORG>; Thu, 26 Oct 1995 23:44:00 -0700
Received: (from julian@localhost) by ref.tfs.com (8.6.12/8.6.12) id XAA01050; Thu, 26 Oct 1995 23:41:37 -0700
From: Julian Elischer <julian@ref.tfs.com>
Message-Id: <199510270641.XAA01050@ref.tfs.com>
Subject: Re: boot disk....
To: msmith@atrad.adelaide.edu.au (Michael Smith)
Date: Thu, 26 Oct 1995 23:41:37 -0700 (PDT)
Cc: terry@lambert.org, msmith@atrad.adelaide.edu.au, lenzi@cwbone.bsi.com.br,
        hackers@FreeBSD.ORG
In-Reply-To: <199510270246.MAA12415@genesis.atrad.adelaide.edu.au> from "Michael Smith" at Oct 27, 95 12:16:16 pm
X-Mailer: ELM [version 2.4 PL24]
Content-Type: text
Content-Length: 2488      
Sender: owner-hackers@FreeBSD.ORG
Precedence: bulk

> 
> 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