From owner-freebsd-current Sun Sep 27 16:03:13 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA06496 for freebsd-current-outgoing; Sun, 27 Sep 1998 16:03:13 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from maddog.u-net.com (p57.nas1.is5.u-net.net [195.102.197.57]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA06357 for ; Sun, 27 Sep 1998 16:02:16 -0700 (PDT) (envelope-from tmb@rcru.rl.ac.uk) Received: from rcru.rl.ac.uk (localhost [127.0.0.1]) by maddog.u-net.com (8.9.1/8.8.8) with ESMTP id XAA05669; Sun, 27 Sep 1998 23:58:18 +0100 (BST) (envelope-from tmb@rcru.rl.ac.uk) Message-Id: <199809272258.XAA05669@maddog.u-net.com> To: Mike Smith cc: freebsd-current@FreeBSD.ORG Subject: Re: 2048-byte sector support for DOS filesystem. In-Reply-To: Your message of "Wed, 09 Sep 1998 08:37:38 PDT." <199809091537.IAA02694@word.smith.net.au> Date: Sun, 27 Sep 1998 23:58:18 +0100 From: Mark Blackman Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199809091537.IAA02694@word.smith.net.au>, Mike Smith writes: >> >> This then would imply (questions of labour aside) that the msdosfs-related >> patches are appropriate for inclusion in CURRENT at some convenient point, no? >> I do understand that there literally hundreds of more important things for >> the kernel gods to address, but I just want to add my (possibly irrelevant) >> vote for increasing it's priority somewhat. > >You could add a lot more weight to the vote by taking the patches, >making sure they apply cleanly, and reporting your test results. This >would really help the issue. Ok, after some of the CAM etc integration dust has settled, I tried the patches in kern/7210. They do not apply in the slightest bit cleanly as they applied to the stable branch and because the FAT32 mods from NetBSD (Feb 18, 1998) appear to have made major changes to a lot of the 'msdosfs' code. More importantly, it appears (to my limited understanding) that the FAT32 mods implemented most or all of the infrastructure necessary to use 'msdosfs' with an arbitrary power-of-2 physical sector size via a 'bnshift' field in the 'pmp' structure. As Bruce pointed out, the only thing 'msdosfs' doesn't use an arbitrary sector size for is reading the boot sector. i.e. /* $Id: msdosfs_vfsops.c,v 1.36 1998/09/07 13:17:02 bde Exp $ */ /* $NetBSD: msdosfs_vfsops.c,v 1.51 1997/11/17 15:36:58 ws Exp $ */ [intervening bits deleted ] /* * Read the boot sector of the filesystem, and then check the * boot signature. If not a dos boot sector then error out. */ #ifdef PC98 error = bread(devvp, 0, 1024, NOCRED, &bp); #else error = bread(devvp, 0, 512, NOCRED, &bp); #endif After reading the code, I realized that the physical sector block size is currently only available *after* the boot sector is read, so I'm not really sure what the answer is. Presumably the sector size is available from some other low-level bit of SCSI/CAM code, but I'm not sure what the appropriate way to get at it is. Any suggestions? Cheers, Mark Blackman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message