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
>
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
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
Hello:
For me if necessary, can add additional comments for it:
If kernel will really need comp2_t in the future (I guess not), kernel
can define it as a union with structures (need not must be the same as
the user mode), which will be easier for kernel using. e.g.
#pragma push(1)
From: Chen Gang
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, k
5 matches
Mail list logo
