Searched hist:"2336 d0deb2d4680349de59d6fbdfc338437be191" (Results 1 – 2 of 2) sorted by relevance
/linux/include/uapi/linux/ |
H A D | fscrypt.h | diff 2336d0deb2d4680349de59d6fbdfc338437be191 Mon Aug 05 04:35:44 CEST 2019 Eric Biggers <ebiggers@google.com> fscrypt: use FSCRYPT_ prefix for uapi constants
Prefix all filesystem encryption UAPI constants except the ioctl numbers with "FSCRYPT_" rather than with "FS_". This namespaces the constants more appropriately and makes it clear that they are related specifically to the filesystem encryption feature, and to the 'fscrypt_*' structures. With some of the old names like "FS_POLICY_FLAGS_VALID", it was not immediately clear that the constant had anything to do with encryption.
This is also useful because we'll be adding more encryption-related constants, e.g. for the policy version, and we'd otherwise have to choose whether to use unclear names like FS_POLICY_V1 or inconsistent names like FS_ENCRYPTION_POLICY_V1.
For source compatibility with existing userspace programs, keep the old names defined as aliases to the new names.
Finally, as long as new names are being defined anyway, I skipped defining new names for the fscrypt mode numbers that aren't actually used: INVALID (0), AES_256_GCM (2), AES_256_CBC (3), SPECK128_256_XTS (7), and SPECK128_256_CTS (8).
Reviewed-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Eric Biggers <ebiggers@google.com>
|
/linux/Documentation/filesystems/ |
H A D | fscrypt.rst | diff 2336d0deb2d4680349de59d6fbdfc338437be191 Mon Aug 05 04:35:44 CEST 2019 Eric Biggers <ebiggers@google.com> fscrypt: use FSCRYPT_ prefix for uapi constants
Prefix all filesystem encryption UAPI constants except the ioctl numbers with "FSCRYPT_" rather than with "FS_". This namespaces the constants more appropriately and makes it clear that they are related specifically to the filesystem encryption feature, and to the 'fscrypt_*' structures. With some of the old names like "FS_POLICY_FLAGS_VALID", it was not immediately clear that the constant had anything to do with encryption.
This is also useful because we'll be adding more encryption-related constants, e.g. for the policy version, and we'd otherwise have to choose whether to use unclear names like FS_POLICY_V1 or inconsistent names like FS_ENCRYPTION_POLICY_V1.
For source compatibility with existing userspace programs, keep the old names defined as aliases to the new names.
Finally, as long as new names are being defined anyway, I skipped defining new names for the fscrypt mode numbers that aren't actually used: INVALID (0), AES_256_GCM (2), AES_256_CBC (3), SPECK128_256_XTS (7), and SPECK128_256_CTS (8).
Reviewed-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Eric Biggers <ebiggers@google.com>
|