2.6 mechanism for holding private inode data

Ok, I finally got a chance to sit down and check this one out. So far so
good, but a couple comments below:

Quoted 2 lines

Quoted 2 lines

The suggested new way of storing private data is to define a new struct that contains your private data and has an inode

imbedded inside.

Quoted 1 line

Quoted 1 line

Then the private data can be reached from an inode by

doing a simple

Quoted 2 lines

Quoted 2 lines

container_of on the inode. This is possible by hooking into inode allocation/deallocation via the alloc_inode/destroy_inode

function

Quoted 3 lines

Quoted 3 lines

pointers in the super operations.

(See linux/Documentation/filesystems/port)

Can we please somehow try to do the similar thing with our 2.4 code? Obviously it's slightly different, but allocating the inode private data
and in 2.4, putting it in inode->u->generic_ip is The Right Thing (TM).
You can use a kmem_cache for both.

Also, please feel free to change our own "void * generic_ip" to an "ocfs_inode *oin" as that's the only type of structure that ever gets put
there.

If you're so setup for 2.6 that testing on a 2.4 kernel is difficult, I'd be
happy to help out by testing on my 2.4 setup :)

I know earlier that I said we wanted to get rid of our macros, but most of
these are one liners. Could you please just keep them in macro form? Also,
if we make things inline, I think we'd want to drop the

all-caps as that
should be reserved for macros. Obviously, we break this rule ourselves in
many places, but much of that is old cruft which we are slowly changing :)
Speaking of which, i noticed that inode_data_is_oin should be upper case as
a macro, so feel free to change that too.

Just curious on why you would ever want to use macros over inline functions? I'll be honest and express my prejudice against macros right here and now :) Since the compiler will convert an inline function into the exact same thing as a macro and you get type checking and predicatable behavior with a inline function.