[OpenAFS-devel] casts vnode<->vcache
Chaskiel M Grundman
cg2v@andrew.cmu.edu
Sat, 23 Mar 2002 21:52:34 -0500
--On Sunday, March 24, 2002 02:02:10 +0100 Johan Danielsson
<joda+openafs@pdc.kth.se> wrote:
> Oh, you mean the nice vrefcount++ hack? I wouldn't call that "works".
Could we stay on-topic please? The behavior of various operating systems'
vrele equivalent has nothing to do with your original point about casting
struct vnode * to struct vcache * and vice-versa.
you said:
> Currently the code does (struct vcache*)vnode all over the place,
> which is fine for systems that either have variable size vnodes, or
> have a large enough vnode to hold a whole vcache.
My response was that the cast is also just fine for systems on which afs
allocates the vnode memory itself. While there may be objections to
what afs does with vnode objects, this isn't one of them.
>> whis is what afs does on all the platforms except OSF/DUX/Tru64.
>
> Which also works only because a struct rnode happens to be larger than
> a struct vcache. Add six more pointers to struct vcache, and
> everything blows up (that this will likely never happen is beside the
> point).
All I was saying was that my statement about where the memory came from
didn't
apply to that OS family. I'm actually surprised that the alpha port was
done this way. Maybe the developers shared your distaste for refcount
trickery.
> For NetBSD you have to call
> getnewvnode, plus use pool_get for the actual vcache data, and then
> write a reclaim routine that pool_puts it back. About 70% of
> afs_NewVCache just vanishes.
I wouldn't say that. afs will presumably still want to bound the number of
vcache objects it allocates, which will require most of that code to remain
intact. In addition, there will presumably need to be code somewhere that
validates vnode<->vcache associations.