Truth, Computing and Fail

  • Home
  • About

Symlinks in a libfs virtual file system: The Pains

anomit | January 7, 2010

The 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 Comments rss
Trackback Trackback

Just what I have been saying

anomit | August 10, 2008

Read this

A detailed post about the problematic mindset plaguing our society in general. Now don’t go about calling it a rant, you dunce.

Some recent developments in my college that is gonna reinforce the points outlined in that post:

1. We are being literally threatened to stop carrying mobiles (and for that matter, any kind of gadgets) otherwise some badass ‘Discipline Enforcement Team’ is gonna conduct ‘raids’ and snatch those from us. No logic, no explanation needed. Shoot shoot, bang bang modern day cowboy. I don’t yet understand what is it with that ‘raid’ terminology. Are we some kinda terrorists or anti-socials?

2. I saw a TGMC poster on the department notice board. Till now there hasn’t been no announcement of it, leave alone which faculty member to contact to register for the event. Looks like the authorities are busier trying to enforce ‘discipline’. I also wonder if they tried telling the IBM people that those in charge of the labs and the so called R&D centre(which now is just another magnificent building converted into a bunch of labs) are too eager to head home after 5 pm and that the college thinks students don’t need internet access from midnight to 5 AM. Oh, did I forget to mention that you won’t get a single fuckin day of attendance even if you managed to get to work on some project under that initiative? If someone with a Microsoft internship and another one with a fractured kneecap didn’t manage to get that, what chance do you stand?

All of these just point to a single fact. They abso-fucking-lutely have nothing better to do.

The only positive development: we are being taught syscalls and my friends are taking interest in writing standardized codes and reading the man pages :D . Only if they made us write the text editor in the Systems Programming lab with ncurses for designing the interface and C instead of just that wretched Turbo C. Yeah, gotoxy() is for losers. Getty?

As for me, I am all tangled up with signals. Classes have been keeping me busy and tired but I hope to get my head around that in a couple of days from now.

Perfection is achieved only at the point of collapse – C.N. Parkinson

Comments
1 Comment »
Categories
Uncategorized
Tags
college, fuckery, syscalls
Comments rss Comments rss
Trackback Trackback

What’s in

  • Symlinks in a libfs virtual file system: The Pains
  • Small rant on the FUSE API reference
  • Kernel module debugging: a simple technique
  • Vim/Cscope quickie
  • PyCon India or Code Jam?

Blogroll

  • Akshay Kothari
  • Ankur Shrivastav (OS)
  • Ankur Sinha
  • Harsh J
  • Hullap
  • LUG manipal
  • Swap

Tags

aircrack airfail airtel assembly blues build c Coding college country cryptography dean faculty file systems fuckery gnuplot hacking India kernel linux mangalore manipal mpd music NASM plugin plugins politicians pub culture python rant rock sam scheduler simulation SSFNet stupidity supernatural suppression syscall syscalls unix vim xchat xml

Archives

  • January 2010
  • December 2009
  • November 2009
  • October 2009
  • September 2009
  • July 2009
  • June 2009
  • May 2009
  • April 2009
  • March 2009
  • January 2009
  • November 2008
  • September 2008
  • August 2008
  • July 2008
  • June 2008
  • May 2008
  • April 2008
  • March 2008
  • February 2008
  • January 2008
  • October 2007
  • September 2007
  • July 2007
  • June 2007
  • May 2007
  • April 2007
  • March 2007

License

Creative Commons License
This work by Anomit Ghosh is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 2.5 India License.
rss Comments rss valid xhtml 1.1 design by jide powered by Wordpress get firefox