Subject: Re: g/c mountcompatnames[] ?
To: =?X-UNKNOWN?Q?Jarom=EDr_Dolecek?= <jdolecek@netbsd.org>
From: Bill Studenmund <wrstuden@zembu.com>
List: tech-kern
Date: 06/27/2001 10:39:25
On Wed, 27 Jun 2001, Jarom=EDr Dolecek wrote:

> Bill Studenmund wrote:
> > I think this might be the first time we drop a COMPAT option. I'm not s=
ure
> > if that's a good thing to do.
> >
> > How is it becoming a maintenance problem - it's not changing, is it?
>=20
> It is changing. It feels ... wrong to add a new filesystem and not update
> list of filesystems in mountcompatnames[], even through that list is obso=
lete.
> Also, due to how current vfs_sysctl() works, that list has to be updated
> and kept in sync and order with CTL_VFS_NAMES in order to support fs sysc=
tls.

Ok, then we've been sloppy about defining our compat option. If the list
is also being used for fs syscalls, then mountcompatnames is a bad
name. Or the compat option is more that you can use a number not a name
(we defined it wrong).

> That stuff is dead weight. It's no longer possible to test if it's
> actually still working. It's been dead for like 7 years now (since
> NetBSD 1.0).

That's not the point I'm trying to make. :-) This would be the first time
we REMOVE a compat option AFAIK. This would be the first time we remove
a compat option AFAIK. This would be the first time we remove a compat
option AFAIK. Especially one which we knew worked right at the time. We
pride ourselves very much on compatability, and here we'd be removing it.

I agree that it's unlikely that there are mount commands still around from
back then, but I know folks have binaries and fs's from back then
still. :-)

As for testing, well, all you have to do is get creative. True none of the
code in the tree will test this option, but that doesn't mean we can't
make a testbed. ;-)

So what does everyone else think?

Take care,

Bill