Re: Help on automatic population of directories

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

On Fri, Mar 05, 2004 at 11:55:09 -0500, Shailabh wrote:
> Hi,
> 
> I'm writing a ram-based filesystem. I want the filesystem to 
> automatically create a few files inside every directory that a user creates.

Why do you want to do it?

One reason to ask that is: The user did not create the files. Should he
really need to delete them manualy?

> I'm trying to do this within the mkdir dir_inode op of the fs
> using code which looks like this:
> 
> >>>>>>>>>>>>>>>>>>
> /* rcfs_mknod and rcfs_get_inode are replicas of corresponding code from 
> fs/ramfs/inode.c */
> 
> static int
> rcfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev)
> {
> 	struct inode * inode = rcfs_get_inode(dir->i_sb, mode, dev);
> 	int error = -ENOSPC, i=0;
> 
> 	if (inode) {
> 		if (dir->i_mode & S_ISGID) {
> 			inode->i_gid = dir->i_gid;
> 			if (S_ISDIR(mode))
> 				inode->i_mode |= S_ISGID;
> 		}
> 		d_instantiate(dentry, inode);
> 		dget(dentry);	/* Extra count - pin the dentry in core */
> 		error = 0;
> 	}
> 	return error;
> }
>
> static int rcfs_mkdir(struct inode * dir, struct dentry * dentry, int mode)
> {
> 	int retval = rcfs_mknod(dir, dentry, mode | S_IFDIR, 0);
> 	/* rcfs_mknod is a complete replica of 
> fs/ramfs/inode.c:ramfs_mknod */
> 
> 	if (!retval)
> 		dir->i_nlink++;

IIRC empty directory has a link-count 2. Thus you should fix it for
dentry->inode too.

> 
> 	/* Do something here to create some "magic" files in this 
> directory before returning to the user */
> 
> 	return retval;
> }
> 
> <<<<<<<<<<<<<<<<<<<<<<<<<<
> 
> Q1: is there sufficient info in the dir/dentry variables  for a file to
> be created within rcfs_mkdir (at the comment point) ? If so, what would 
> be the best way to do this ?

You must be _very_ careful to avoid deadlock, but it should be possible
to do almost anything here. (Generaly, locking i_sem must be ordered by
address, but an inode that you didn't publish yet can be locked safely.)

So you have two basic choices:
1) Call ->create method on the newly created inode (or ->mknod if you
   are making a special node).
2) Set some additional info on the new inode and pick the tab later in
   lookup. ... and readdir.

> Q2: How can one find the vfsmnt given the dentry of a directory that has
> just been created ?

Don't do it unless you must. You shouldn't need it here.

> I was thinking of using d_path() to lookup the complete path of the 
> just-created directory and then calling a modified version of sys_mknod
> on the resulting string. Probably not the best way of doing this but it
> was simpler to understand :-)

Oh, HORRORS! That's a very bad way to do it -- remember, that you
already hold the parent directory. So you can simply call it's methods.
... actualy, you should call the do_ or vfs_ subroutines for the
syscalls, which are the main workhorses.

> But I'm having trouble determining the
> vfsmnt from the dentry returned from rcfs_mknod - I tried using
> current->namespace->root and also current->fs->rootmnt with no success -
> dpath returns blank or garbage as the resulting string and not 
> "/rcfs/hello/" which is what I expect when directory hello is being created.

You see the garbage when you directly printk it, or when you call
a sys_* function on it? In the second case, mind the copy_(to|from)_user!

> I'm new to filesystem development and still not completely clear about 
> the relationships between mount points, dentries etc....Any pointers on
> useful functions would be much appreciated !

It's rather bad unfortunately. There are few files in Documentation
describing locking scheme and very basic semantics of the methods (it's
VERY good to have these handy when programming). Other documentation
tends to be outdated. The source is quite easy to understand, however.
(Hope you heared of http://lxr.linux.no/source)

-------------------------------------------------------------------------------
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]