From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Hudec Subject: Re: Help on automatic population of directories Date: Sat, 6 Mar 2004 21:51:31 +0100 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <20040306205131.GC17554@vagabond> References: <4048B0ED.1010702@watson.ibm.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Cc: linux-fsdevel Return-path: Received: from cimice4.lam.cz ([212.71.168.94]:20434 "EHLO vagabond.light.src") by vger.kernel.org with ESMTP id S261715AbUCFUvm (ORCPT ); Sat, 6 Mar 2004 15:51:42 -0500 To: Shailabh Content-Disposition: inline In-Reply-To: <4048B0ED.1010702@watson.ibm.com> List-Id: linux-fsdevel.vger.kernel.org --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Mar 05, 2004 at 11:55:09 -0500, Shailabh wrote: > Hi, >=20 > I'm writing a ram-based filesystem. I want the filesystem to=20 > automatically create a few files inside every directory that a user creat= es. 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: >=20 > >>>>>>>>>>>>>>>>>> > /* rcfs_mknod and rcfs_get_inode are replicas of corresponding code from= =20 > fs/ramfs/inode.c */ >=20 > static int > rcfs_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev) > { > struct inode * inode =3D rcfs_get_inode(dir->i_sb, mode, dev); > int error =3D -ENOSPC, i=3D0; >=20 > if (inode) { > if (dir->i_mode & S_ISGID) { > inode->i_gid =3D dir->i_gid; > if (S_ISDIR(mode)) > inode->i_mode |=3D S_ISGID; > } > d_instantiate(dentry, inode); > dget(dentry); /* Extra count - pin the dentry in core */ > error =3D 0; > } > return error; > } > > static int rcfs_mkdir(struct inode * dir, struct dentry * dentry, int mod= e) > { > int retval =3D rcfs_mknod(dir, dentry, mode | S_IFDIR, 0); > /* rcfs_mknod is a complete replica of=20 > fs/ramfs/inode.c:ramfs_mknod */ >=20 > if (!retval) > dir->i_nlink++; IIRC empty directory has a link-count 2. Thus you should fix it for dentry->inode too. >=20 > /* Do something here to create some "magic" files in this=20 > directory before returning to the user */ >=20 > return retval; > } >=20 > <<<<<<<<<<<<<<<<<<<<<<<<<< >=20 > 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= =20 > 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=20 > 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. =2E.. 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=20 > "/rcfs/hello/" which is what I expect when directory hello is being creat= ed. 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=20 > 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 --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFASjnSRel1vVwhjGURAgj8AJ4jxGItoYErXCYphoLj3ld5Jc902gCgtKs2 pwWzonQ+96FlmMisH1H855g= =SGoh -----END PGP SIGNATURE----- --ZmUaFz6apKcXQszQ--