linux-kernel - Re: [PATCH] uapi: linux: acct: Remove redundant type comp2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <580ABCBD.6080401@emindsoft.com.cn>
Date:   Sat, 22 Oct 2016 09:11:25 +0800
From:   Chen Gang <chengang@...ndsoft.com.cn>
To:     Andrew Morton <akpm@...ux-foundation.org>
CC:     dhowells@...hat.com, linux-kernel@...r.kernel.org,
        Chen Gang <gang.chen.5i5j@...il.com>
Subject: Re: [PATCH] uapi: linux: acct: Remove redundant type comp2_t from
 kernel

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 chengang@...ndsoft.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.