Date: Sun, 27 Sep 1998 23:58:18 +0100 From: Mark Blackman <tmb@rcru.rl.ac.uk> To: Mike Smith <mike@smith.net.au> Cc: freebsd-current@FreeBSD.ORG Subject: Re: 2048-byte sector support for DOS filesystem. Message-ID: <199809272258.XAA05669@maddog.u-net.com> In-Reply-To: Your message of "Wed, 09 Sep 1998 08:37:38 PDT." <199809091537.IAA02694@word.smith.net.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809272258.XAA05669>