From owner-freebsd-hackers Tue Oct 13 19:20:35 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA19032 for freebsd-hackers-outgoing; Tue, 13 Oct 1998 19:20:35 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA19025 for ; Tue, 13 Oct 1998 19:20:32 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost.cdrom.com [127.0.0.1]) by dingo.cdrom.com (8.9.1/8.8.8) with ESMTP id TAA03030; Tue, 13 Oct 1998 19:23:59 -0700 (PDT) (envelope-from mike@dingo.cdrom.com) Message-Id: <199810140223.TAA03030@dingo.cdrom.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Terry Lambert cc: mike@smith.net.au (Mike Smith), karpen@ocean.campus.luth.se, hackers@FreeBSD.ORG Subject: Re: BETA problems... In-reply-to: Your message of "Wed, 14 Oct 1998 01:31:27 -0000." <199810140131.SAA22082@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Oct 1998 19:23:59 -0700 From: Mike Smith Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Actually, you could MD5 the first N sectors of the disk using both VM86() > > > I/O and kernel I/O, and if the MD5 matched, you've found your drive. > > > > Given that we've established that disk I/O via our vm86 interface is > > problematic (you were part of this discussion, remember?), this is a > > non-possibility. It'll have to be done by the bootstrap. > > I was, but I don't rememebr why it was problematic. I remember that > there were issues specific to the attempted implementation, and > which I thought were architectural issues not related to whether or > not the access method was a good idea. My take on it was "If it > can be done by Microsoft engineers, it can be done by FreeBSD engineers". It appears that it would involved bogotising our interrupt handling structure. I don't believe we're willing to take that penalty, so you can effectively write off any hope of vm86-based disk I/O from the kernel. > > > If you have two drives that MD5 the same, tweak an unused portion > > > of one of them using VM86() I/O and see which one got tweaked using > > > kernel I/O, and, again, you've found your drive. > > > > Define "unused". > > Assuming that VM86() is an issue, the bytes in the cylinder following > the disklabel and boot sector, whose end is identifiable by 0xaa55. ... where our bootstrap lives? Where the NT bootstrap lives? > Alternately "anything that won't interfere with me booting, and > which I will know to put back later". For example, if we allowed > FreeBSD to boot off both an 0xa5 partition type and another partition > type, then the partition type could be toggled to one or the other > without affecting the bootability of FreeBSD. There's probably a junk field somewhere, sure. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message