From here on we will be trying to stick somewhat close to the design

factoring typical of Linux filesystems, as exemplified by Ext2 and

Ext3.  The immediate effort is to make Tux3's open_inode fill the role

of Ext2's ext2_get_inode.
We see that ext2_get_inode is called from only two places:
   http://lxr.linux.no/linux+v2.6.26.3/+ident=14702139
References:

	fs/ext2/inode.c, line 1104 <- definition

	fs/ext2/inode.c, line 1205 <- called from ext2_iget

	fs/ext2/inode.c, line 1316 <- called from ext2_update_inode
In general, *_iget is used to create or retrieve an inode from backing

store and *_update_inode is used to sync an inode to backing store.  In

the first case a new, empty vfs struct inode is created immediately at

the beginning of the process and in the second, the struct inode

already exists.  This suggests a slightly different factoring than Ext2

uses that better reflects the fact that Tux3's method of finding its

way to an inode on disk is considerably more involved than Ext2's, and

that Ext2 has separate bitmaps dedicated to allocating inodes which

allow it to avoid reading the any actual inode table blocks until later

when the new inode has to be synced to disk.
A quick tour of ext2 functions that create inodes:
Look up an inode:
   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/namei.c#L66

   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/namei.c#L73
Get the root directory
   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/super.c#L1044
Weird NFS hack:
   http://lxr.linux.no/linux+v2.6.26.3/fs/ext2/super.c#L330
Create a new inode
   ext2_new_inode(dir, mode);
which uses ialloc, looking only at the inode bitmaps, to create a new inode.

But in Tux3 we dive down into the inode btree itself to allocate an inode,

just as we do when we look it up or update it.  We want a somewhat different

factoring to reflect this.
Skeleton code for Ext2:
   inode = ext2_

      inode = ext2_new_inode(dir, mode)

         inode = new_inode(sb)

         inum = ialloc(dir)

      ext2_add_link(...)
   inode = ext2_iget(sb, name, len)

      inode = iget_locked(sb, ino)
      ext2_get_inode(inum, &buffer)
   ext2_update_inode(inode)

      ext2_get_inode(inum, &buffer)
Skeleton code for Tux3:
   inode = tux3_

      inode = tux3_create(sb, name, len, iattrs)

         inode = new_inode(sb)

         tux3_get_inode(inum, &buffer, iattrs)
         tux3_create_entry(dir, name, len...))
   inode = tux3_iget(sb, name, len)

      inode = iget_locked(sb, ino)
      inode = tux3_open(sb, name, len)

         tux3_get_inode(inum, &buffer, NULL)
   tux3_isync(inode)

      tux3_get_inode(inum, &buffer, NULL)
So tux3_get_inode is to combine functionality of three ext2 functions:

ext2_new_inode, ext2_get_inode and ext2_update_inode.  This places the

inode btree handling logic (lookup, create and update) in exactly one

place, and also centralizes the attribute encoding and decoding, which

is considerably more complex than Ext2's.  Still, we stay quite close

to Ext2's structure.  If we can keep achieving small victories like

that then the kernel port should be pretty easy.
Regards,
Daniel
_______________________________________________

Tux3 mailing list

Tux3@tux3.org

http://tux3.org/cgi-bin/mailman/listinfo/tux3