[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1B91A6E6-7F4A-4C58-93E7-394217C1631C@dilger.ca>
Date: Mon, 4 May 2020 16:26:35 -0600
From: Andreas Dilger <adilger@...ger.ca>
To: Jonny Grant <jg@...k.org>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: /fs/ext4/ext4.h add a comment to ext4_dir_entry_2
> On May 3, 2020, at 6:52 AM, Jonny Grant <jg@...k.org> wrote:
>
> Hello
>
> Could a comment be added to clarify 'file_type' ?
>
> struct ext4_dir_entry_2 {
> __le32 inode; /* Inode number */
> __le16 rec_len; /* Directory entry length */
> __u8 name_len; /* Name length */
> __u8 file_type;
> char name[EXT4_NAME_LEN]; /* File name */
> };
>
>
>
> This what I am proposing to add:
>
> __u8 file_type; /* See directory file type macros below */
For this kind of structure field, it makes sense to reference the macro
names directly, like:
__u8 file_type; /* See EXT4_FT_* type macros below */
since "macros below" may be ambiguous as the header changes over time.
Even better (IMHO) is to use a named enum for this, like:
enum ext4_file_type file_type:8; /* See EXT4_FT_ types below */
/*
* Ext4 directory file types. Only the low 3 bits are used. The
* other bits are reserved for now.
*/
enum ext4_file_type {
EXT4_FT_UNKNOWN = 0,
EXT4_FT_REG_FILE = 1,
EXT4_FT_DIR = 2,
EXT4_FT_CHRDEV = 3,
EXT4_FT_BLKDEV = 4,
EXT4_FT_FIFO = 5,
EXT4_FT_SOCK = 6,
EXT4_FT_SYMLINK = 7,
EXT4_FT_MAX,
EXT4_FT_DIR_CSUM = 0xDE
};
so that the allowed values for this field are clear from the definition.
However, the use of a fixed-with bitfield (enum :8) is a GCC-ism and Ted
may be against that for portability reasons, since the kernel and
userspace headers should be as similar as possible.
Cheers, Andreas
Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)
Powered by blists - more mailing lists