On 10/22/16 06:53, Chen Gang wrote: > > On 10/21/16 11:41, Andrew Morton wrote: >> On Wed, 5 Oct 2016 21:40:10 +0800 cheng...@emindsoft.com.cn wrote: >> >>> In api itself, kernel does not use it -- it is divided into ac_etime_hi >>> and ac_etime_lo. So kernel side only need generate the correct >>> ac_etime_hi and ac_etime_lo, but need not know about comp2_t. >>> >>> At present, kernel use normal u64 type for it, when kernel provdes it to >>> outside, kernel can translate it into ac_etime_hi and ac_etime_lo, >>> directly, but need not notice about comp2_t, in fact. >> >> hm. Why is this an improvement? >> > > For me, it will let code a little more understanding, a little simpler, > and let the code a little more extendable (when kernel members really > needs comp2_t in future, they need not have to treat it as __u32). > > Only when comp2_t is really used in api header in future, kernel has to > know about it, but kernel still can keep original code no touch. So for > me, our changing is harmless. >
Oh sorry, for "Only when comp2_t is really used in api header in future", we may need encode_comp2_t, but in kernel wide, this changing is very small. At present, only encode_comp2_t uses comp2_t, and it is only called by fill_ac in an area, and the goal of fill_ac is to encode etime to ac ( comp2_t is the intermediate generation). And I guess, we have very small chance to use comp2_t in uapi header in future, so now, encode_comp2_t can be removed, when we really need it, we can revert to encode_comp2_t and let encode_ac_etime_hilo call it. Thanks -- Chen Gang (陈刚) Managing Natural Environments is the Duty of Human Beings.