From owner-freebsd-hackers Mon Mar 17 21:46:01 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id VAA04484 for hackers-outgoing; Mon, 17 Mar 1997 21:46:01 -0800 (PST) Received: from lestat.nas.nasa.gov (lestat.nas.nasa.gov [129.99.50.29]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id VAA04471 for ; Mon, 17 Mar 1997 21:45:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by lestat.nas.nasa.gov (8.7.5/8.6.12) with SMTP id VAA13412; Mon, 17 Mar 1997 21:43:24 -0800 (PST) Message-Id: <199703180543.VAA13412@lestat.nas.nasa.gov> X-Authentication-Warning: lestat.nas.nasa.gov: Host localhost [127.0.0.1] didn't use HELO protocol To: Michael Smith Cc: hackers@freebsd.org Subject: Re: wd driver questions Reply-To: Jason Thorpe From: Jason Thorpe Date: Mon, 17 Mar 1997 21:43:21 -0800 Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Tue, 18 Mar 1997 15:51:33 +1030 (CST) Michael Smith wrote: > Thing wot uses simplistic file services to assemble from data on > disk (kernel link instructions, object files) a kernel and runs it. ...oh... I rather like just having A Kernel Image and loading it :-) > Bearing in mind that my POV is still fairly x86/FreeBSD-centric, no I do > _not_ want block numbers in my bootstrap 8) ...well, it actually makes somethings a fair bit simpler... Basically, you're talking about two-stage there... but the only reason to use two-stage is space constraints (stupid limit on PCs, space until file system begins on SPARCs, etc.) If you don't hardcode the block numbers of the secondary boot program into the primary, you have to include all the file system reading code, which sort of defeats "small". installboot(8) deals with all of it anyhow, and since you currently have to run something to stash the primary bootstrap into the right sector, it's not that big of a deal :-) > Ick. (Is the old one _that_ bad? Where can documentation on the > Fuji part be obtained? This is getting off-thread...) (Yah, a little off-topic, but what the Hell :-) The current NetBSD/hp300 SCSI driver suffers from the following problems: - doesn't use NetBSD's MI SCSI code - is "simplistic" ... doesn't implement any interesting SCSI features like disconnect/reselect. Hey, when the driver was written, people were happy to have something other than HP-IB... sigh, how times change :-) I have complete documentation on the Fujitsu chip ... What I lack now is the time to work on it. Jason R. Thorpe thorpej@nas.nasa.gov NASA Ames Research Center Home: 408.866.1912 NAS: M/S 258-6 Work: 415.604.0935 Moffett Field, CA 94035 Pager: 415.428.6939