[Lustre-devel] OFLAGS change.

[Liu, Xuezhao]

"if i correctly understand - that change have a dependence to the OPEN_FMODE macro - not a kernel version.
so for any kernels have a OPEN_FMODE - we need to use that function, otherwise use flags directly."

OPEN_FMODE was introduced at kernel 2.6.34 (5300990c0370e804e49d9a59d928c5d53fb73487).
open_to_namei_flags was changed at kernel 3.1 (8a5e929dd2e05ab4d3d89f58c5e8fca596af8f3a).
So we cannot only depend on OPEN_FMODE for that.

Thanks,
Xuezhao
-----Original Message-----
From: lustre-devel-bounces at lists.lustre.org [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Alexey Lyahkov
Sent: 2012年12月20日 19:07
To: Peng, Tao
Cc: hpdd-discuss at lists.01.org; WC-Discuss; <lustre-devel at lists.lustre.org>
Subject: [Lustre-devel] OFLAGS change.


On Dec 20, 2012, at 06:32, Peng, Tao wrote:
>> 
>> 
>>> reason to use autoconf macroses - we can't trust a RHEL/SuSe kernel 
>>> version/
> Well, there are situations that autoconf cannot handle properly, such as the open_flag change by upstream commit (8a5e929dd2e05ab4d3d89f58c5e8fca596af8f3a). The change is inline so we cannot tell it without grepping the source file (fs/namei.c) which is likely unavailable when users build Lustre client from source. We currently solved it by putting a LINUX_VERSION_CODE check there but as you see it is not trustworthy when vendors backport patches.
> 
> And IMO, the right way to solve such problems is to put Lustre in upstream/stable kernels and let vendors ship it so that they match in the first place.


static inline int ll_namei_to_lookup_intent_flag(int flag) { #if LINUX_VERSION_CODE >= KERNEL_VERSION(3, 1, 0) <------>flag = (flag & ~O_ACCMODE) | OPEN_FMODE(flag); #endif <------>return flag; }

if i correctly understand - that change have a dependence to the OPEN_FMODE macro - not a kernel version.
so for any kernels have a OPEN_FMODE - we need to use that function, otherwise use flags directly.

----------------------------------------------
Alexey Lyahkov
alexey_lyashkov at xyratex.com


_______________________________________________
Lustre-devel mailing list
Lustre-devel at lists.lustre.org
http://lists.lustre.org/mailman/listinfo/lustre-devel