This wont work very well because AFS expects to be able to access
those structure elements, and if they change order it would be
bad.
Now, we could go back to what I did back in Linux-AFS:
struct vnode_t {
struct inode v_in;
<rest of stuff>
};
-derek
"Neulinger, Nathan" <nneul@umr.edu> writes:
> Something I was wondering about with this... it's just an idea, but tell me
> what y'all think.
>
> if afs only needs to add additional stuff to the end of this structure for
> it's own use, why not have the build process do the following:
>
> In configure:
> get the sizeof(the kernel structure)
>
> then, generate a prototype for struct vnode_t that basically
> consists of
>
> struct vnode_t {
> char pad[ the size ];
> <whatever afs needs to add>
> };
>
> Now, that won't help in the mismatched-compile case, but it would certainly
> eliminate the need to be adding extra fields all the time.
>
> If afs needs access to any of the elements within the kernel structure
> (besides it's own field), just cast it first.
>
> There's probably some reason why this wouldn't work, but I just figured I'd
> throw it out.
>
> ....
>
> Or for that matter, why couldn't the structure just be defined like:
>
> struct vnode_t {
> struct inode inode;
> /* extra stuff here */
> };
>
> and then make a few macros for accessing the internal part of the structure.
> Since it's the first element, vnode.inode.x should be the same address as
> inode.x, which should satisfy the kernel itself I would think.
>
> -- Nathan
>
> > -----Original Message-----
> > From: Jeffrey Hutzelman [mailto:jhutz@cmu.edu]
> > Sent: Wednesday, August 08, 2001 6:00 AM
> > To: Steven N. Hirsch
> > Cc: Derrick J Brashear; openafs-info@openafs.org
> > Subject: Re: [OpenAFS] Strange Behavior of Openafs-1.1.1
> >
> >
> > On Tue, 7 Aug 2001, Steven N. Hirsch wrote:
> >
> > > Pardon my density, but I grepped the sources for anything
> > that looked like
> > > it was supposed to parallel those structures and found
> > nothing except
> > > an inline inclusion in osi_vfs.h. Are you saying that this
> > is filled
> > > through clandestine means like memcpy? If so, I can well
> > understand the
> > > problem.
> >
> > The problem here is that structures of type 'struct vnode_t'
> > as defined in
> > src/afs/LINUX/osi_vfs.h are frequently passed to kernel code which
> > expects a 'struct inode'. Thus, the order and size of
> > elements in these
> > two structures must be the same. So, whenever the inode
> > structure changes
> > in Linux, AFS must be modified to reflect the change. It's a
> > pain, and
> > will eventually be fixed, but that's the source of your problem.
> >
> > -- Jeff
> >
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available