Specification of the Umsdos file system for LINUX

# Convention and style

[linux/fs/umsdos/inode.c,366]
#Specification: function name / convention

A simple convention for function name has been used in the UMSDOS file system. First all function use the prefix umsdos_ to avoid name clash with other part of the kernel.

And standard VFS entry point use the prefix UMSDOS (upper case) so it's easier to tell them apart.

[linux/fs/umsdos/namei.c,757]
#Specification: style / iput strategy

In the UMSDOS project, I am trying to apply a single programming style regarding inode management. Many entry point are receiving an inode to act on, and must do an iput() as soon as they are finished with the inode.

For simple case, there is no problem. When you introduce error checking, you end up with many iput placed around the code.

The coding style I use all around is one where I am trying to provide independent flow logic (I don't know how to name this). With this style, code is easier to understand but you rapidly get iput() all around. Here is an exemple of what I am trying to avoid.

    	if (a){
    	    ...
    	    if(b){
    	        ...
    	    }
    	    ...
    	    if (c){
    	        // Complex state. Was b true ?
    	        ...
    	    }
    	    ...
    	}
    	// Weird state
    	if (d){
    	    // ...
    	}
    	// Was iput finally done ?
    	return status;

Here is the style I am using. Still sometime I do the first when things are very simple (or very complicated :-( )

    	if (a){
    	    if (b){
    	        ...
    	    }else if (c){
    	        // A single state gets here
    	    }
    	}else if (d){
    	    ...
    	}
    	return status;

Again, while this help clarifying the code, I often get a lot of iput(), unlike the first style, where I can place few "strategic" iput(). "strategic" also mean, more difficult to place.

So here is the style I will be using from now on in this project. There is always an iput() at the end of a function (which has to do an iput()). One iput by inode. There is also one iput() at the places where a successful operation is achieved. This iput() is often done by a sub-function (often from the msdos file system). So I get one too many iput() ? At the place where an iput() is done, the inode is simply nulled, disabling the last one.

    	if (a){
    	    if (b){
    	        ...
    	    }else if (c){
    	        msdos_rmdir(dir,...);
    	        dir = NULL;
    	    }
    	}else if (d){
    	    ...
    	}
    	iput (dir);
    	return status;

Note that the umsdos_lockcreate() and umsdos_unlockcreate() function pair goes against this practice of "forgetting" the inode as soon as possible.

[linux/fs/umsdos/inode.c,28]
#Specification: convention / PRINTK Printk and printk

Here is the convention for the use of printk inside fs/umsdos

printk carry important message (error or status). Printk is for debugging (it is a macro defined at the beginning of most source. PRINTK is a nulled Printk macro.

This convention makes the source easier to read, and Printk easier to shut off.