relayfs redux for 2.6.10: lean and mean

I've reworked the relayfs patch extensively. The API and internals have been heavily purged. The patch is in fact almost HALF! its original size, loosing 90KB and going from 200KB to 110KB.

Hm, how about this idea for cutting about 500 more lines from the code:

Why not drop the "fs" part of relayfs and just make the code a set of struct file_operations. That way you could have "relayfs-like" files in any ram based file system that is being used. Then, a user could use these fops and assorted interface to create debugfs or even procfs files using this type of interface.

As relayfs really is almost the same (conceptually wise) as debugfs as far as concept of what kinds of files will be in there (nothing anyone would ever rely on for normal operations, but for debugging only) this keeps users and developers from having to spread their debugging and instrumenting files from accross two different file systems.

Quoted 8 lines · Greg KH

Hm, how about this idea for cutting about 500 more lines from the code:

Why not drop the "fs" part of relayfs and just make the code a set of struct file_operations. That way you could have "relayfs-like" files in any ram based file system that is being used. Then, a user could use these fops and assorted interface to create debugfs or even procfs files using this type of interface.

Quoted 5 lines

As relayfs really is almost the same (conceptually wise) as debugfs as far as concept of what kinds of files will be in there (nothing anyone would ever rely on for normal operations, but for debugging only) this keeps users and developers from having to spread their debugging and instrumenting files from accross two different file systems.

However this assumes that the users of relayfs are not going to want it during normal system operation. This is an assumption that fails with at least LTT as it is targeted at sysadmins, application developers and power users who need to be able to trace their systems at any time.

I don't mind piggy-backing off another fs, if it makes sense, but unlike debugfs, relayfs is meant for general use, and all files in there are of the same type: relay channels for dumping huge amounts of data to user-space. It seems to me the target audience and basic idea (relay channels only in the fs) are different, but let me know if there's a compeling argument for doing this in another way without making it too confusing for users of those special "files" (IOW, when this starts being used in distros, it'll be more straightforward for users to understand if all files in a mounted fs behave a certain way than if they have certain "odd" files in certain directories, even if it's /proc.)

Perhaps the logical solution is to implement debugfs in terms of relayfs?

Quoted 1 line · Peter Williams

Perhaps the logical solution is to implement debugfs in terms of relayfs?

What do you mean by this statement?

Quoted 5 lines · Greg KH

Quoted 1 line · Peter Williams

Perhaps the logical solution is to implement debugfs in terms of relayfs?

Quoted 1 line

What do you mean by this statement?

I mean that if, as you say, debugfs is very similar to relayfs only more restricted (i.e. a debugging option) then it should be implementable as an instance or specialization of the more general relayfs and that this should be a better solution than two independent implementations of similar functionality.

Quoted 8 lines · Greg KH

Hm, how about this idea for cutting about 500 more lines from the code:

Why not drop the "fs" part of relayfs and just make the code a set of struct file_operations. That way you could have "relayfs-like" files in any ram based file system that is being used. Then, a user could use these fops and assorted interface to create debugfs or even procfs files using this type of interface.

Quoted 5 lines

As relayfs really is almost the same (conceptually wise) as debugfs as far as concept of what kinds of files will be in there (nothing anyone would ever rely on for normal operations, but for debugging only) this keeps users and developers from having to spread their debugging and instrumenting files from accross two different file systems.

However this assumes that the users of relayfs are not going to want it during normal system operation.

This is an assumption that fails with at least LTT as it is targeted at sysadmins, application developers and power users who need to be able to trace their systems at any time.

I don't mind piggy-backing off another fs, if it makes sense, but unlike debugfs, relayfs is meant for general use, and all files in there are of the same type: relay channels for dumping huge amounts of data to user-space.

It seems to me the target audience and basic idea (relay channels only in the fs) are different, but let me know if there's a compeling argument for doing this in another way without making it too confusing for users of those special "files" (IOW, when this starts being used in distros, it'll be more straightforward for users to understand if all files in a mounted fs behave a certain way than if they have certain "odd" files in certain directories, even if it's /proc.)

Are they willing to trade off the performance of LTT to get this? I thought this was being touted as a "when you need to test" type of thing, not a "run it all the time" type of feature.

And a driver will never want to have both a relay channel, and a simple debug output at the same time? You are now requiring them to look for that data in two different points in the fs.

So, since you are proposing that relayfs be mounted all the time, where do you want to mount it at? I had to provide a "standard" location for debugfs for people to be happy with it, and the same issue comes up here.

Also, why not export your relayfs ops so that someone useing debugfs can create a relay channel in it, or in any other type of fs they might create?

fs/relayfs/inode.c +4 -0

+	if (inode) {
+		d_instantiate(dentry, inode);
+		dget(dentry);	/* Extra count - pin the dentry in core */
+		error = 0;

fs/relayfs/inode.c +11 -0

+}
+
+static int
+relayfs_symlink(struct inode * dir, struct dentry *dentry, const char * symname)
+{
+	struct inode *inode;
+	int error = -ENOSPC;
+
+	inode = relayfs_get_inode(dir->i_sb, S_IFLNK|S_IRWXUGO, 0);
+
+	if (inode) {

fs/relayfs/inode.c +46 -0

+
+/**
+ *	relayfs_create_entry - create a relayfs directory or file
+ *	@name: the name of the file to create
+ *	@parent: parent directory
+ *	@dentry: result dentry
+ *	@entry_type: type of file to create (S_IFREG, S_IFDIR)
+ *	@mode: mode
+ *	@data: data to associate with the file
+ *
+ *	Creates a file or directory with the specifed permissions.
+ */
+static int
+relayfs_create_entry(const char * name, struct dentry * parent, struct dentry **dentry, int entry_type, int mode, void * data)
+{
+	struct qstr qname;
+	struct dentry * d;
+
+	int error = 0;
+
+	error = simple_pin_fs("relayfs", &relayfs_mount, &relayfs_mount_count);
+	if (error) {
+		printk(KERN_ERR "Couldn't mount relayfs: errcode %d\n", error);
+		return error;
+	}
+
+	qname.name = name;
+	qname.len = strlen(name);
+	qname.hash = full_name_hash(name, qname.len);
+
+	if (parent == NULL)
+		if (relayfs_mount && relayfs_mount->mnt_sb)
+			parent = relayfs_mount->mnt_sb->s_root;
+
+	if (parent == NULL) {
+		simple_release_fs(&relayfs_mount, &relayfs_mount_count);
+ 		return -EINVAL;
+	}
+
+	parent = dget(parent);
+	down(&parent->d_inode->i_sem);
+	d = lookup_hash(&qname, parent);
+	if (IS_ERR(d)) {
+		error = PTR_ERR(d);
+		goto release_mount;
+	}

fs/Makefile +20 -0

+/**
+ *	alloc_page_array - alloc array to hold pages, but not pages
+ *	@size: the total size of the memory represented by the page array
+ *	@page_count: the number of pages the array can hold
+ *	@err: 0 on success, negative otherwise
+ *
+ *	Returns a pointer to the page array if successful, NULL otherwise.
+ */
+static struct page **
+alloc_page_array(int size, int *page_count, int *err)
+{
+	int n_pages;
+	struct page **page_array;
+	int page_array_size;
+
+	*err = 0;
+
+	size = PAGE_ALIGN(size);
+	n_pages = size >> PAGE_SHIFT;
+	page_array_size = n_pages * sizeof(struct page *);

fs/Makefile +13 -0

+/**
+ *	rchan_create - allocate and initialize a channel, including buffer
+ *	@chanpath: path specifying the relayfs channel file to create
+ *	@bufsize: the size of the sub-buffers within the channel buffer
+ *	@nbufs: the number of sub-buffers within the channel buffer
+ *	@rchan_flags: flags specifying buffer attributes
+ *	@err: err code
+ *
+ *	Returns channel if successful, NULL otherwise, err receives errcode.
+ *
+ *	Allocates a struct rchan representing a relay channel, according
+ *	to the attributes passed in via rchan_flags.  Does some basic sanity
+ *	checking but doesn't try to do anything smart.  In particular, the

To solve the problem I applied a patch similar to the one you posted back in July and it fixed the problem. Could we consider putting this patch into relayfs? Its similar to the one posted in July 2004, except it also moves clear_readers() before INIT_WORK in relay_release (is that acceptable?).

To solve the problem I applied a patch similar to the one you posted back in July and it fixed the problem. Could we consider putting this patch into relayfs? Its similar to the one posted in July 2004, except it also moves clear_readers() before INIT_WORK in relay_release (is that acceptable?).

Quoted 7 lines · Kingsley Cheung

To solve the problem I applied a patch similar to the one you posted back in July and it fixed the problem. Could we consider putting this patch into relayfs? Its similar to the one posted in July 2004, except it also moves clear_readers() before INIT_WORK in relay_release (is that acceptable?).

Yes, for some reason the July patch never got applied to that (now outdated) 2.6.10 version of relayfs - either that patch or yours should fix the problem - thanks for sending it. In any case, the version of relayfs you're using is now ancient history - the latest redux versions of relayfs recently posted to lkml have completely changed or removed all that code, so you might want to try testing with the latest patch (which I'm still reworking parts of even now).

Thanks,

Tom