From owner-freebsd-hackers Sun Mar 19 00:48:42 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA02719 for hackers-outgoing; Sun, 19 Mar 1995 00:48:42 -0800 Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.34]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA02708 for ; Sun, 19 Mar 1995 00:48:33 -0800 Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.9/8.6.9) id SAA12153; Sun, 19 Mar 1995 18:45:26 +1000 Date: Sun, 19 Mar 1995 18:45:26 +1000 From: Bruce Evans Message-Id: <199503190845.SAA12153@godzilla.zeta.org.au> To: phk@ref.tfs.com, rgrimes@gndrsh.aac.dev.com Subject: Re: kern/248: scbus attach/probe printf inconsistency Cc: bde@zeta.org.au, dufault@hda.com, freebsd-hackers@freefall.cdrom.com, pst@Shockwave.COM Sender: hackers-owner@FreeBSD.org Precedence: bulk >> Ahh, we misunderstand each other! >> >> I'm only talking about sd.c, not wd.c. >> >> For wd.c disks the information has a very real value, for scsi: absolutely >> none. >For scsi the only unreal value is sectors/track. All other values are >as reported by the drive. I think this is why the wd info is more valuable. The IDE drives that I'm familiar with (not many) report translated values in wdgetctlr(). For drives smaller than 504MB, it is possible for the translated values to be usable both in the partition table and for accessing the drive, so there is little possiblity of confusion. I think the translated values become unsuitable for accessing the drive above 504MB, so wd.c breaks. Some drives report more-physical values in a place that `struct wdparams' doesn't support. The driver doesn't really need to know about these - it can invent a suiatble geomtry. Bruce