From owner-freebsd-hackers Tue Jul 30 15:25:04 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id PAA13272 for hackers-outgoing; Tue, 30 Jul 1996 15:25:04 -0700 (PDT) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id PAA13249; Tue, 30 Jul 1996 15:24:58 -0700 (PDT) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id PAA00825; Tue, 30 Jul 1996 15:23:50 -0700 From: Terry Lambert Message-Id: <199607302223.PAA00825@phaeton.artisoft.com> Subject: Re: anyone working on upgrading the msdosfs to NetBSD levels? To: rnordier@iafrica.com (Robert Nordier) Date: Tue, 30 Jul 1996 15:23:50 -0700 (MST) Cc: terry@lambert.org, hackers@freebsd.org, current@freebsd.org In-Reply-To: <199607302117.XAA00293@eac.iafrica.com> from "Robert Nordier" at Jul 30, 96 11:17:46 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > I have a beta copy of this in house right now. It is intended > > solely for the OEM market. I think it will require a reinstall > > to share the disk in any case, since FIPS/PARTED/etc. doesn't > > understand the disk layout. In general, you will only ever see > > it on preinstalled systems. > [...] > > > > I think it's ready now. The limiting factor is going to be MS's OEM > > release date. > > > > Don't expect to install VFAT32 yourself, since NT can't mount VFAT32 > > partitions, and MS wants everyone to move to NT (Windows95 has always > > been billed as a transition product). > > Good to have your comments, Terry. > > Would it be correct to say you consider VFAT32 support not worth the > effort, or am I reading too much between the lines? The installation I have will "upgrade" an existing system. Whether VFAT32 becomes rampant will depend on whether they give it as an option. Right now, an upgrade kills NT, and the sector-based allocation table that replaces the partition table kills NT on dual-boot systems. I believe that they would have to release or announce NT support before they would be willing to let people use the version I have. The current estimate for Windows95's life cycle is 2 years before there is a unification of NT/95 to get a single Win32 based OS. If they release the VFAT32 for 95 without releasing it for NT, then the life cycle for Windows95 grows to 2 years + (the "+" being the delay in the NT release to allow upgrades). NT already has a problem with DriveSpace drives, and there are a lot of shops running NT on FAT FS's because FAT is actually *faster* than NTFS. I don't think Microsoft will kill NT on purpose. On the other hand, support for it can't hurt. The replacement for the partition table is bound to make it into NT even if nothing else does. I think the partition translation problem is logically seperate from the FAT FS itself (I think it will go into physical-to-logical device mapping in DEVFS), so it would be possible to support it without supporting the VFAT32 FS proper. Expect to need support for it in no less than a year, if ever. If I were writing a VFATFS, I would macro the calls to do the actual reads/writes and stick device range checking in a function layer that you can expect to go away in a later incarnation. Return "EINVAL" and do the logical to physical offset translation in your layer. All new FS's should expect to work on a "device" that is totally committed to the FS and looks like it starts at offset 0, and return EINVAL or EFAULT for out of range operations on the device. If this were there now, then the MSDOSFS would be incapable of corrupting non-MSDOSFS disk areas with the current code. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.