inode of anonymity file

[Valdis.Kletnieks at vt.edu]

On Wed, 11 Sep 2013 18:30:31 +0800, Grissiom said:
> I found that `anon_inode_getfd` and `anon_inode_getfile` could create
> anonymity files that I could implement my own read/write etc without both
> writing "drivers" nor expose the structure into the file system.

I suspect that your understanding of why anonymous files exist is a bit murky..

> But when I dig into the source code, I fount all the files created by them
> will share the same inode. Will it causing problems? Will other anon files
> interfere with my own anon files? If one anon file get deleted or closed,
> will I lost the inode of my own anon file?

Hint:  Anonymous files basically exist only to make sure that functions that
demand a pointer to an inode don't oops. Examples are epoll and signalfd and
friends.

You can't actually use an anonymous inode to reference anything on a filesystem.

There's also the concept of an "unlinked file", which is somewhat different.
That's a file that is no longer listed in any directory, but still exists
because a program still has an open file descriptor.  The unlink() system call
removes the name/inode pair from the directory, but does not actually reap the
inode itself until the reference count drops to zero  (because the alternative
is ripping the file out from under the program that still has an open file
descriptor is a lot harder than it looks).

And of course, unlinked files don't have much long-term use either - if you
don't use the linkat() system call to reconnect it, it's going to go bye-bye
when your program exits....

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20130911/f455c137/attachment.bin