Re: fixing coda in -current

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Nov 20, 2018 at 08:25:38PM +1030, Brett Lymn wrote:
 > I am guessing that not many people use coda (or they just haven't
 > complained) as it seems like the coda kernel support has suffered some
 > bit-rot.  Trying to access a coda file system on -current results in a
 > couple of KASSERTs firing - the first is easy, we need to lock the vnode
 > on readdir but after doing that there is a check in ufs_readwrite.c to
 > ensure the vnode is either a VDIR or VLNK type, neither of which is true
 > for coda because the whole coda file system is contained in a regular
 > file on the host file system so the vnode type is VREG.  The following
 > patch makes coda work for me.  I don't think that manipulating the vnode
 > type is really great but a lesser evil than trying to create a duplicate
 > of the ufs readdir code and also not as bad as removing the KASSERTs
 > which are useful sanity checks in the majority of use cases.

So I have no immediate comment on the patch but I'd like to understand
better what it's doing -- the last time I crawled around in it
(probably 7-8 years ago) it appeared to among other things have an
incestuous relationship with ufs_readdir such that if you tried to use
anything under than ffs as the local container it would detonate
violently. But I never did figure out exactly what the deal was other
than it was confusing and seemed to violate a lot of abstractions.

Can you clarify? It would be nice to have it working properly and
stuff like the above is only going to continue to fail in the future...

-- 
David A. Holland
dholland%netbsd.org@localhost