Symlinks in a libfs virtual file system: The Pains
anomit | January 7, 2010The only documentation you have got for libfs is the code itself, which says a lot about the hoops I had to jump through to at least get this thing working 
I still don’t claim that I know all the innards of libfs regarding this functionality. It took me around 3 days, poking around the code and quite a few kernel freezes and oops to figure this thing out. Also to be noticed is the fact is that this is for a non disk-based file system like /proc. I guess things will be different when it’s done on file systems like ext3.
WARNING: This is quite a long drawn post as I haven’t presented the solution in a straight forward manner. I have rather chosen to ramble on about my personal experience. For a no-nonsense, tldr-free answer, visit this
To begin with, I was absolutely clueless. All this time I had been using `ln -s` or symlink() without worrying about what really goes on under the hood. Imagine my frustration when ln -s didn’t work on the file system. I had completely neglected this part and thought that it’d be somehow taken care of automagically.
Going through a few online resources, I managed to deduce that the symlink operation takes place on inode level (whatever you make of that). Looking through the fields of struct inode , I found struct i_op for inode operations. Referring to both the book Understanding Linux Kernel and the source code for the fields in i_op, I found out a few function pointers that had something to do with links, namely symlink(), readlink(), follow_link().
Initially, I thought of implementing getattr() so that it’d return a S_IFLNK for the symlink but the idea of having to handle attribute generation for the rest of the dentry objects was too much for my puny brain and this plan was discarded.
Reading through man 2 symlink, I came across this and instantly everything was clear:
Symbolic links are interpreted at run time as if the contents of the link had been substituted into the path being followed to find a file or directory.
First, I changed the file creation function a bit for the symlink so that the proper st_mode is set and put the target location string in the i_private field of the inode structure.
Then I created a inode_operations structure and put in the following function definitions:
static void *sample_follow_link (struct dentry *dentry, struct nameidata *nd)
{
nd->depth = 0;
nd_set_link(nd, (char *)dentry->d_inode->i_private);
return NULL;
}
static struct inode_operations sample_inode_ops = {
.readlink = generic_readlink,
.follow_link = sample_follow_link,
};
....
//in the function for the dentry and inode creation
inode->i_op = sample_inode_ops
But it was the second step that actually took up the most of my time. I read the man page of readlink and naively put in my own readlink implementation.
int sample_readlink(struct dentry *dentry, char __user *buffer, int buflen)
{
unsigned long ret = copy_to_user(buffer, dentry->d_inode->i_private, buflen);
if (ret == 0)
return buflen;
else
return -EFAULT;
}
Kernel freezes happened and wailing of wolves were heard in the distance. Putting in just generic_readlink didn’t solve the problem either with kernel oops happening every time ls was run. Looking into the function definition of generic_readlink in the kernel source, I found it’s mentioned in the corresponding comment block that follow_link needs to be implemented for it to work. Looking into the code for ext2 gave me some idea about dealing with struct nameidata. Problem solved
- Comments
- 1 Comment »
- Categories
- Coding, GNU/Linux
- Tags
- c, file systems, inode, kernel, libfs, linux, syscalls, vfs
Comments rss
Trackback
