Re: [PATCH] Documentation: add initial iomap kdoc

[Randy Dunlap <rdunlap@infradead.org>]

On 5/19/23 02:28, Bagas Sanjaya wrote:
>> +/**
>> + * DOC:  Flags reported by the file system from iomap_begin
>>   *
>> - * IOMAP_F_NEW indicates that the blocks have been newly allocated and need
>> - * zeroing for areas that no data is copied to.
>> + * * IOMAP_F_NEW: indicates that the blocks have been newly allocated and need
>> + *	zeroing for areas that no data is copied to.
>>   *
>> - * IOMAP_F_DIRTY indicates the inode has uncommitted metadata needed to access
>> - * written data and requires fdatasync to commit them to persistent storage.
>> - * This needs to take into account metadata changes that *may* be made at IO
>> - * completion, such as file size updates from direct IO.
>> + * * IOMAP_F_DIRTY: indicates the inode has uncommitted metadata needed to access
>> + *	written data and requires fdatasync to commit them to persistent storage.
>> + *	This needs to take into account metadata changes that *may* be made at IO
>> + *	completion, such as file size updates from direct IO.
>>   *
>> - * IOMAP_F_SHARED indicates that the blocks are shared, and will need to be
>> - * unshared as part a write.
>> + * * IOMAP_F_SHARED: indicates that the blocks are shared, and will need to be
>> + *	unshared as part a write.
>>   *
>> - * IOMAP_F_MERGED indicates that the iomap contains the merge of multiple block
>> - * mappings.
>> + * * IOMAP_F_MERGED: indicates that the iomap contains the merge of multiple block
>> + *	mappings.
>>   *
>> - * IOMAP_F_BUFFER_HEAD indicates that the file system requires the use of
>> - * buffer heads for this mapping.
>> + * * IOMAP_F_BUFFER_HEAD: indicates that the file system requires the use of
>> + *	buffer heads for this mapping.
>>   *
>> - * IOMAP_F_XATTR indicates that the iomap is for an extended attribute extent
>> - * rather than a file data extent.
>> + * * IOMAP_F_XATTR: indicates that the iomap is for an extended attribute extent
>> + *	rather than a file data extent.
>>   */
> Why don't use kernel-doc comments to describe flags?
> 

Because kernel-doc handles functions, structs, unions, and enums.
Not defines.

-- 
~Randy