Lines Matching refs:to
19 interface to userspace programs. It also provides an abstraction
20 within the kernel which allows different filesystem implementations to
32 calls. The pathname argument that is passed to them is used by the VFS
33 to search through the directory entry cache (also known as the dentry
34 cache or dcache). This provides a very fast look-up mechanism to
36 in RAM and are never saved to disc: they exist only for performance.
38 The dentry cache is meant to be a view into your entire filespace. As
40 some bits of the cache are missing. In order to resolve your pathname
41 into a dentry, the VFS may have to resort to creating dentries along
49 An individual dentry usually has a pointer to an inode. Inodes are
53 disc are copied into the memory when required and changes to the inode
54 are written back to disc. A single inode can be pointed to by multiple
61 things like open(2) the file, or stat(2) it to peek at the inode
63 dentry, it peeks at the inode data and passes some of it back to
73 a pointer to the dentry and a set of file operation member functions.
80 is done by using the userspace file descriptor to grab the appropriate
81 file structure, and then calling the required file structure method to
98 request is made to mount a filesystem onto a directory in your namespace,
100 filesystem. New vfsmount referring to the tree returned by ->mount()
101 will be attached to the mountpoint, so that when pathname resolution
104 You can see all filesystems that are registered to the kernel in the
132 mount: the method to call when a new instance of this
135 kill_sb: the method to call when an instance of this filesystem
138 owner: for internal VFS use: you should initialize this to THIS_MODULE in
141 next: for internal VFS use: you should initialize this to NULL
158 caller. An active reference to its superblock must be grabbed and the
165 struct super_block accordingly, returning its root dentry to caller.
167 ->mount() may choose to return a subtree of existing filesystem - it
168 doesn't have to create a new one. The main result from the caller's
169 point of view is a reference to dentry at the root of (sub)tree to
173 mount() method fills in is the "s_op" field. This is a pointer to
195 int silent: whether or not to be silent on error
240 alloc_inode: this method is called by alloc_inode() to allocate memory
243 alloc_inode will be used to allocate a larger structure which
246 destroy_inode: this method is called by destroy_inode() to release
251 dirty_inode: this method is called by the VFS to mark an inode dirty.
253 write_inode: this method is called when the VFS needs to write an
254 inode to disc. The second parameter indicates whether the write
257 drop_inode: called when the last access to the inode is dropped,
262 want to cache inodes - causing "delete_inode" to always be
265 The "generic_delete_inode()" behavior is equivalent to the
270 delete_inode: called when the VFS wants to delete an inode
272 put_super: called when the VFS wishes to free the superblock
286 statfs: called when the VFS needs to get filesystem statistics.
295 show_options: called by the VFS to show mount options for
298 quota_read: called by the VFS to read from filesystem quota file.
300 quota_write: called by the VFS to write to filesystem quota file.
303 filesystem to return the number of freeable cached objects it contains.
307 filesystem to scan the number of objects indicated to try to free them.
308 Optional, but any filesystem implementing this method needs to also
309 implement ->nr_cached_objects for it to be called correctly.
313 the VM is trying to reclaim under GFP_NOFS conditions, hence this
314 method does not need to handle that situation itself.
317 scanning loop that is done. This allows the VFS to determine
318 appropriate scan batch sizes without having to worry about whether
319 implementations will cause holdoff problems due to large scan batch
323 is a pointer to a "struct inode_operations" which describes the methods that
374 required if you want to support regular files. The dentry you
379 lookup: called when the VFS needs to look up an inode in a parent
380 directory. The name to look for is found in the dentry. This
381 method must call d_add() to insert the found inode into the
388 If you wish to overload the dentry methods then you should
390 to a struct "dentry_operations".
394 to support hard links. You will probably need to call
398 want to support deleting inodes
401 want to support symlinks. You will probably need to call
405 to support creating subdirectories. You will probably need to
409 to support deleting subdirectories
411 mknod: called by the mknod(2) system call to create a device (char,
413 if you want to support creating these types of inodes. You
414 will probably need to call d_instantiate() just as you would
417 rename: called by the rename(2) system call to rename the object to
420 rename2: this has an additional flags argument compared to rename.
429 implementation is equivalent to plain rename.
435 you want to support reading symbolic links
437 follow_link: called by the VFS to follow a symbolic link to the
438 inode it points to. Only required if you want to support
440 that is passed to put_link().
442 put_link: called by the VFS to release resources allocated by
444 to this method as the last parameter. It is used by
450 permission: called by the VFS to check for access rights on a POSIX-like
455 storing to the inode.
460 setattr: called by the VFS to set attributes for a file. This method
463 getattr: called by the VFS to get attributes of a file. This method
466 setxattr: called by the VFS to set an extended attribute for a file.
470 getxattr: called by the VFS to retrieve the value of an extended
474 listxattr: called by the VFS to list all extended attributes for a
477 removexattr: called by the VFS to remove an extended attribute from
480 update_time: called by the VFS to update a specific time or the i_version of
487 turned out to be wrong) it may signal this by returning 1 instead of
494 tmpfile: called in the end of O_TMPFILE open(). Optional, equivalent to
500 The address space object is used to group and manage pages in the page
501 cache. It can be used to keep track of the pages in a file (or
510 The first can be used independently to the others. The VM can try to
511 either write dirty pages in order to clean them, or release clean
512 pages in order to reuse them. To do this it can call the ->writepage
515 references will be released without notice being given to the
518 To achieve this functionality, pages need to be placed on an LRU with
519 lru_cache_add and mark_page_active needs to be called whenever the
528 ->writepages method. It uses the tag to find dirty pages to call
532 __sync_single_inode) to check if ->writepages has been successful in
536 via filemap_fdatawait_range, to wait for all writeback to
538 each page that is found to require writeback.
540 An address_space handler may attach extra information to a page,
543 cause various VM routines to make extra calls into the address_space
544 handler to deal with that data.
548 time, and provided to the application either by copying of the page,
551 written-back to storage typically in whole pages, however the
556 set_page_dirty to write data into the address_space, and writepage,
557 sync_page, and writepages to writeback data to storage.
559 Adding and removing pages to/from an address_space is protected by the
562 When data is written to a page, the PG_Dirty flag should be set. It
563 typically remains set until writepage asks for it to be written. This
565 written at any point after PG_Dirty is clear. Once it is known to be
573 This describes how the VFS can manipulate mapping of a file to page cache in
594 /* migrate the contents of a page to the specified target */
605 writepage: called by the VM to write a dirty page to backing store.
607 to free up memory (flush). The difference can be seen in
614 If wbc->sync_mode is WB_SYNC_NONE, ->writepage doesn't have to
615 try too hard if there are problems, and may choose to write out
616 other pages from the mapping if that is easier (e.g. due to
617 internal dependencies). If it chooses not to start writeout, it
623 readpage: called by the VM to read a page from backing store.
626 If ->readpage discovers that it needs to unlock the page for
631 writepages: called by the VM to write out pages associated with the
638 tagged as DIRTY and will pass them to ->writepage.
640 set_page_dirty: called by the VM to set a page dirty.
642 private data to a page, and that data needs to be updated when
648 readpages: called by the VM to read pages associated with the address_space
653 ignored. If anything goes wrong, feel free to give up.
656 Called by the generic buffered write code to ask the filesystem to
657 prepare to write len bytes at the given offset in the file. The
658 address_space should check that the write will be able to complete,
665 offset, in *pagep, for the caller to write into.
667 It must be able to cope with short writes (where the length passed to
680 be called. len is the original len passed to write_begin, and copied
681 is the amount that was able to be copied (copied == len is always true
688 that were able to be copied into pagecache.
690 bmap: called by the VFS to map a logical block offset within object to
692 ioctl and for working with swap-files. To be able to swap to
693 a file, the file must have a stable mapping to a block
695 but instead uses bmap to find out where the blocks in the file
699 alternative to f_op->open(), the difference is that this method may open
702 which want to allow native I/O directly on underlying files.
706 will be called when part or all of the page is to be removed
707 from the address space. This generally corresponds to either a
711 should be updated to reflect this truncation. If offset is 0 and
713 because the page must be able to be completely discarded. This may
717 releasepage: releasepage is called on PagePrivate pages to indicate
724 wants to make it a free page. If ->releasepage succeeds, the
727 The second case is when a request has been made to invalidate
733 If the filesystem makes such a call, and needs to be certain
735 need to ensure this. Possibly it can clear the PageUptodate
739 the page cache in order to allow the cleanup of any private
744 direct_IO: called by the generic read/write routines to perform
749 migrate_page: This is used to compact the physical memory usage.
750 If the VM wants to relocate a page (maybe off a memory card
752 and an old page to this function. migrate_page should
754 that it has to the page.
762 block is up to date then the read can complete without needing the IO
763 to bring the whole page up to date.
765 is_dirty_writeback: Called by the VM when attempting to reclaim a page.
766 The VM uses dirty and writeback information to determine if it needs
767 to stall to allow flushers a chance to complete some IO. Ordinarily
770 do not set those flags due to locking problems (jbd). This callback
771 allows a filesystem to indicate to the VM if a page should be
774 error_remove_page: normally set to generic_error_remove_page if truncation
779 swap_activate: Called when swapon is used on a file to allocate
782 in which case this file can be used to back swapspace. The
783 swapspace operations will be proxied to this address space's
835 llseek: called when the VFS needs to move the file position index
845 iterate: called when the VFS needs to read the directory contents
847 poll: called by the VFS when a process wants to check if there is
848 activity on this file and (optionally) go to sleep until there
863 done the way it is because it makes filesystems simpler to
864 implement. The open() method is a good place to initialize the
865 "private_data" member in the file structure if you want to point
866 to a device structure
868 flush: called by the close(2) system call to flush a file
870 release: called when the last reference to an open file is closed
886 splice_write: called by the VFS to splice data from a pipe to a file. This
889 splice_read: called by the VFS to splice data from file to a pipe. This
892 setlease: called by the VFS to set or release a file lock lease. setlease
893 implementations should call generic_setlease to record or remove
896 fallocate: called by the VFS to preallocate blocks or punch a hole.
903 operations with those for the device driver, and then proceed to call
919 here. These methods may be set to NULL, as they are either optional or
937 d_revalidate: called when the VFS needs to revalidate a dentry. This
949 blocking or storing to the dentry, d_parent and d_inode should not be
956 d_weak_revalidate: called when the VFS needs to revalidate a "jumped" dentry.
963 d_revalidate, most local filesystems will set this to NULL since their
970 d_hash: called when the VFS adds a dentry to the hash table. The first
971 dentry passed to d_hash is the parent directory that the name is
972 to be hashed into.
975 what is safe to dereference etc.
977 d_compare: called to compare a dentry name with a given name. The first
978 dentry is the parent of the dentry to be compared, the second is
980 to be compared. qstr is the name to compare it with.
991 It is a tricky calling convention because it needs to be called under
994 d_delete: called when the last reference to a dentry is dropped and the
995 dcache is deciding whether or not to cache it. Return 1 to delete
996 immediately, or 0 to cache the dentry. Default is NULL which means to
1002 d_iput: called when a dentry loses its inode (just prior to its
1008 Useful for some pseudo filesystems (sockfs, pipefs, ...) to delay
1011 dont want to use it, because their dentries are present in global
1013 held, d_dname() should not try to modify the dentry itself, unless
1015 tricky. The correct way to return for example "Hello" is to put it
1016 at the end of the buffer, and returns a pointer to the first char.
1017 dynamic_dname() helper function is provided to take care of this.
1019 d_automount: called when an automount dentry is to be traversed (optional).
1020 This should create a new VFS mount record and return the record to the
1022 automount directory to describe the automount target and the parent
1023 VFS mount record to provide inheritable mount parameters. NULL should
1024 be returned if someone else managed to make the automount first. If
1027 ordinary directory and returned to pathwalk to continue walking.
1029 If a vfsmount is returned, the caller will attempt to mount it on the
1032 it to prevent automatic expiration - the caller will clean up the
1039 d_manage: called to allow the filesystem to manage the transition from a
1040 dentry (optional). This allows autofs, for example, to hold up clients
1041 waiting to explore behind a 'mountpoint' whilst letting the daemon go
1042 past and construct the subtree there. 0 should be returned to let the
1043 calling process continue. -EISDIR can be returned to tell pathwalk to
1044 use this directory as an ordinary directory and to ignore anything
1045 mounted on it and not to check the automount flag. Any other error
1050 and the caller can be asked to leave it and call again by returning
1051 -ECHILD. -EISDIR may also be returned to tell pathwalk to
1065 Each dentry has a pointer to its parent dentry, as well as a hash list
1073 There are a number of functions defined which permit a filesystem to
1080 the usage count drops to 0, and the dentry is still in its
1081 parent's hash, the "d_delete" method is called to check whether
1084 into an LRU list to be reclaimed on memory shortage.
1087 subsequent call to dput() will deallocate the dentry if its
1088 usage count drops to 0
1090 d_delete: delete a dentry. If there are no other open references to
1095 d_add: add a dentry to its parents hash list and then calls
1098 d_instantiate: add a dentry to the alias hash list for the inode and
1109 to free the dentry when it finishes using it.
1125 options. There are plenty of examples on how to use it in existing
1132 to show all the currently active options. The rules are:
1145 The underlying reason for the above rules is to make sure, that a
1158 (Note some of these resources are not up-to-date with the latest kernel