This patch add an anonymous inode source, to be used for files that need 
and inode only in order to create a file*. We do not care of having an 
inode for each file, and we do not even care of having different names in 
the associated dentries (dentry names will be same for classes of file*).
This allow code reuse, and will be used by epoll, signalfd and timerfd 
(and whatever else there'll be).



Signed-off-by: Davide Libenzi <davidel@xmailserver.org>



- Davide



Index: linux-2.6.21-rc3.quilt/fs/anon_inodes.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6.21-rc3.quilt/fs/anon_inodes.c	2007-03-19 19:01:27.000000000 -0700
@@ -0,0 +1,204 @@
+/*
+ *  fs/anon_inodes.c
+ *
+ *  Copyright (C) 2007  Davide Libenzi <davidel@xmailserver.org>
+ *
+ *  Thanks to Arnd Bergmann for code review and suggestions.
+ *  More changes for Thomas Gleixner suggestions.
+ */
+
+#include <linux/file.h>
+#include <linux/poll.h>
+#include <linux/slab.h>
+#include <linux/init.h>
+#include <linux/fs.h>
+#include <linux/mount.h>
+#include <linux/module.h>
+#include <linux/kernel.h>
+#include <linux/magic.h>
+#include <linux/anon_inodes.h>
+
+#include <asm/uaccess.h>
+
+
+
+static int ainofs_delete_dentry(struct dentry *dentry);
+static struct inode *aino_mkinode(void);
+static int ainofs_get_sb(struct file_system_type *fs_type, int flags,
+			 const char *dev_name, void *data, struct vfsmount *mnt);
+
+
+
+static struct vfsmount *aino_mnt __read_mostly;
+static struct inode *aino_inode;
+static const struct file_operations aino_fops = { };
+static struct file_system_type aino_fs_type = {
+	.name		= "ainofs",
+	.get_sb		= ainofs_get_sb,
+	.kill_sb	= kill_anon_super,
+};
+static struct dentry_operations ainofs_dentry_operations = {
+	.d_delete	= ainofs_delete_dentry,
+};
+
+
+
+/**
+ * aino_getfd - creates a new file instance by hooking it up to and anonymous
+ *              inode, ...
[ message continues ]

On Tue, 20 Mar 2007 11:37:14 -0700




If this is moved elsewhere we can perhaps remove some or all of the



Dunno about others, but the "aino" naming doesn't grab me, really. 
anon_inode_getfd() would make more sense.

We conventionally use `const char *' rather than `char const *', and I thnk





Can we make this optional if CONFIG_EMBEDDED?  You plan on converting epoll

-

[ message continues ]

It'd be interesting to know how much is enough. You use one, ppl says it 
is too dense. You use more, ppl says it's too much.
There's the one-line rule for inter-function spacing, but what's the 

Same here. You're the third says this, so I'm gonna change it. But pls 






Same thing used in pipes. Avoid loading the hash for things that'll never 



Ok, it was panincing, and someone made me change it. Would you please 
agree?

Hmmm, the whole point is that all this stuff works with or without epoll. 
And epoll need no changes to support this.



- Davide


-

[ message continues ]

Yes, it's just [nice] text.

But the function description needs to fit on one line.  If that's
not enough, put more description after the @params lines, separated
by a
 *
"blank" line.


---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-

[ message continues ]

On Fri, 30 Mar 2007 15:44:15 -0700 (PDT)


I'd say panic.  There's no much point in limping along with an
incorrectly-working kernel, only to have some small number of apps fail

I'm suggesting that all known clients of anon_inode be made optional. 
Hence anon_iode can become optional too.

It's a desirable objective, at least.  The default, really.
-

[ message continues ]

Ok, I'll put them under Kconf.



- Davide


-

[ message continues ]

Well, in this case (since it's at bootup only), I'd agree with panic(), 
but generally I disagree - it's actually much better to have a broken 
system limping along and allowing things like syslogd to write the problem 
to log-files and generally working as well as possible.

If people can do a "dmesg" and send it out as an email, we're much more 
likely to get good bug-reports.

But for early boot, and for something that can't really happen anyway, 
panic() sounds fine.

		Linus
-

[ message continues ]