On Thu, Sep 12, 2013 at 1:28 AM, <Valdis.Kletnieks@xxxxxx> wrote: > > 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. > Yes. I'm award of that. I've see the source code of fs/timerfd.c and got a basic idea of anonymous inodes. So I should re-state my question: what is the relationship between inode and "struct file" and file descriptors? inode and fd should be one-to-many, but how about inode and "strut file"? And which operation on fd will affect inode? It seems read(2)/write(2) have nothing to do with the inode associated with the fd? > 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.... > One question about the unlinked file: if I write a lot of data into a unlinked file, where will the data be? On the disk or in the RAM? If the data will be on the disk, where is it? -- Cheers, Grissiom _______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
