[OpenAFS-devel] porting openafs to another linux - problems w ith vRefcount type..

[Neulinger, Nathan]

Right now, the patch I did was pretty simple, I'm not positive it fully
works (haven't tried yet) but it compiles clean:


Index: src/afs/LINUX/osi_vfs.hin
===================================================================
RCS file: /cvs/openafs/src/afs/LINUX/osi_vfs.hin,v
retrieving revision 1.1
diff -u -r1.1 osi_vfs.hin
--- src/afs/LINUX/osi_vfs.hin   2001/10/01 22:59:01     1.1
+++ src/afs/LINUX/osi_vfs.hin   2001/10/05 18:48:27
@@ -27,7 +27,11 @@
 
 /* Map vnode fields to inode fields. */
 #define i_number       i_ino
+#if defined(AFS_PARISC_LINUX24_ENV)
+#define v_count                i_count.counter
+#else
 #define v_count                i_count
+#endif
 #define v_op           i_op
 #if defined(AFS_LINUX24_ENV)
 #define v_fop           i_fop
@@ -57,7 +61,11 @@
 #define FSYNC O_SYNC
 
 #define VTOI(V)  ((struct inode*)V)
+#if defined(AFS_PARISC_LINUX24_ENV)
+#define VN_HOLD(V) ((vnode_t*)V)->i_count.counter++;
+#else
 #define VN_HOLD(V) ((vnode_t*)V)->i_count++;
+#endif
 #define VN_RELE(V) osi_iput((struct inode *)V);
 #define VFS_STATFS(V, S) ((V)->s_op->statfs)((V), (S), sizeof(*(S)))
 


something similar that checked for any 2.4.x kernel would probably fit the
bill nicely. 

Although it would be better to use the atomic_* interfaces I'd say. But that
would require cleaning up stray references to it throughout the code.
(Probably a good thing to do anyway.)

-- Nathan

> -----Original Message-----
> From: chas williams [mailto:chas@cmf.nrl.navy.mil]
> Sent: Friday, October 05, 2001 2:03 PM
> To: Nickolai Zeldovich
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] porting openafs to another linux 
> - problems
> with vRefcount type.. 
> 
> 
> >change to automatically generate the vnode structure from struct
> >inode made the refcount atomic_t instead of int.  I've sent a bug
> >report to openafs-bugs@openafs.org about it, but haven't heard
> >anything back yet.  Probably easiest workaround for now is to
> 
> i am the guilty party on this one.  when i was doing the 2.4 port i
> didnt change that over due to the large number of changes that would
> be needed.  i shouldnt be so lazy.
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>