Return to BSD News archive
Newsgroups: comp.os.386bsd.questions
Path: sserve!newshost.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!gatech!news.byu.edu!ns.novell.com!gateway.univel.com!fcom.cc.utah.edu!cs.weber.edu!terry
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: NetBSD and DOS coexistence ?
Message-ID: <1993May17.201629.21507@fcom.cc.utah.edu>
Sender: news@fcom.cc.utah.edu
Organization: Weber State University (Ogden, UT)
References: <1t5kqp$mh4@lucy.ee.und.ac.za> <1993May16.212102.6346@fcom.cc.utah.edu> <vanepp.737612701@sfu.ca>
Date: Mon, 17 May 93 20:16:29 GMT
Lines: 58
In article <vanepp.737612701@sfu.ca> vanepp@fraser.sfu.ca (Peter Van Epp) writes:
>terry@cs.weber.edu (A Wizard of Earth C) writes:
>
>>4) How to smarten up install so this BS isn't necessary.
>
>> Basically, the second stage boot needs to record the translated
>> geometry information in a memory area not tromped by the kernel
>> on startup. The kernel needs to record the information in a
>> local area during init and make it available through a special
>> ioctl() to all disk devices. Fortunately, there is a convenient
>> block of memory not already in use to do this: the unused bounce
>> buffer hunk.
>
>Does this indicate that the DIOCGDINFO ioctl that returns the disklabel
>structure that Julian's SCSI driver has filled in is sometimes not correct?
>I have a set of patches for pfdisk that use this to get the geometry under
>386BSD and it appears to work on my Adaptec. Several other people have been
>given copies (hopefully to test with other disk types) but I haven't heard
>any results yet.
NO!
The DIOCGDINFO ioctl() returns the current disk label; what I was referring
to was the way the information got *into* the disklabel in the first place.
It's my suggestion that it be the result of the disklabel (or replacement
program) getting the information passed to it by way of the secondary boot
(which already has the information available from having talked to the
hardware) rather than by way of a human typing in the cylinders, heads, and
sectors (humans are notoriously unreliable data sources).
The only tricky part is the cylinder count in the translated geometry, since
larger disks will have had this truncated to 1024 (the maximum value allowed
to DOS in any translation). On *BIG* disks, this can be a problem; for
instance, my 1778 cylinder untranslated Maxtor Panther P1-17S has 19 heads
and 86 sectors; the translated values of 64 and 32 for heads and sectors
means that disklabel should be told that there are 1448 cylinders *NOT* 1024
so that the largest amount of space possible is made usable.
Since your pfdisk port uses the *existing* disklabel and my suggestions are
to change the method of *creating* the disklabel, there isn't any conflict.
The one danger may be that the geometry reported by your port of pfdisk
will not match that repoorted by the DOS pfdisk, and that partition
changes based on that information made in 386BSD may invalidate any data
you write out there (making the disk, potentially, unbootable).
Hope that clarifies things.
Terry Lambert
terry@icarus.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
"I have an 8 user poetic license" - me