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.

Reply via email to