ShuriZma
/
xemu
mirror of https://github.com/xemu-project/xemu.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

9pfs/codir.c: convert Doxygen -> kerneldoc format 

API doc comments in QEMU are supposed to be in kerneldoc format, so
convert API doc comments from Doxygen format to kerneldoc format.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
Reviewed-by: Greg Kurz <groug@kaod.org>
Message-Id: <c76be7d38ea448c6417b2ffb5ccd6b711519a878.1646314856.git.qemu_oss@crudebyte.com>
This commit is contained in:
Christian Schoenebeck 2022-03-03 13:52:14 +01:00
parent 39db334719
commit 1a7f240014
1 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
hw/9pfs/codir.c
View File

@ -184,14 +184,25 @@ out:
}
/**
* @brief Reads multiple directory entries in one rush.
* v9fs_co_readdir_many() - Reads multiple directory entries in one rush.
*
* @pdu: the causing 9p (T_readdir) client request
* @fidp: already opened directory where readdir shall be performed on
* @entries: output for directory entries (must not be NULL)
* @offset: initial position inside the directory the function shall
* seek to before retrieving the directory entries
* @maxsize: maximum result message body size (in bytes)
* @dostat: whether a stat() should be performed and returned for
* each directory entry
* Return: resulting response message body size (in bytes) on success,
* negative error code otherwise
*
* Retrieves the requested (max. amount of) directory entries from the fs
* driver. This function must only be called by the main IO thread (top half).
* Internally this function call will be dispatched to a background IO thread
* (bottom half) where it is eventually executed by the fs driver.
*
* @discussion Acquiring multiple directory entries in one rush from the fs
* Acquiring multiple directory entries in one rush from the fs
* driver, instead of retrieving each directory entry individually, is very
* beneficial from performance point of view. Because for every fs driver
* request latency is added, which in practice could lead to overall
@ -199,20 +210,9 @@ out:
* directory) if every directory entry was individually requested from fs
* driver.
*
* @note You must @b ALWAYS call @c v9fs_free_dirents(entries) after calling
* NOTE: You must ALWAYS call v9fs_free_dirents(entries) after calling
* v9fs_co_readdir_many(), both on success and on error cases of this
* function, to avoid memory leaks once @p entries are no longer needed.
*
* @param pdu - the causing 9p (T_readdir) client request
* @param fidp - already opened directory where readdir shall be performed on
* @param entries - output for directory entries (must not be NULL)
* @param offset - initial position inside the directory the function shall
* seek to before retrieving the directory entries
* @param maxsize - maximum result message body size (in bytes)
* @param dostat - whether a stat() should be performed and returned for
* each directory entry
* @returns resulting response message body size (in bytes) on success,
* negative error code otherwise
* function, to avoid memory leaks once @entries are no longer needed.
*/
int coroutine_fn v9fs_co_readdir_many(V9fsPDU *pdu, V9fsFidState *fidp,
struct V9fsDirEnt **entries,