--On Sunday, March 24, 2002 02:02:10 +0100 Johan Danielsson <[EMAIL PROTECTED]> 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. _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
