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....
Attachment:
pgpM0A57BITfG.pgp
Description: PGP signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
