[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: anyone working on upgrading the msdosfs to NetBSD levels?
From:       Terry Lambert <terry () lambert ! org>
Date:       1996-07-30 22:23:50
[Download RAW message or body]

> > 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.

[prev in list] [next in list] [prev in thread] [next in thread]