From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755774AbcJVBIe (ORCPT ); Fri, 21 Oct 2016 21:08:34 -0400 Received: from out28-218.mail.aliyun.com ([115.124.28.218]:58233 "EHLO out28-218.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755474AbcJVBIc (ORCPT ); Fri, 21 Oct 2016 21:08:32 -0400 X-Greylist: delayed 303 seconds by postgrey-1.27 at vger.kernel.org; Fri, 21 Oct 2016 21:08:31 EDT X-Alimail-AntiSpam: AC=CONTINUE;BC=0.07890448|-1;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03295;MF=chengang@emindsoft.com.cn;NM=1;PH=DS;RN=4;RT=4;SR=0;TI=SMTPD_---.74sqvnr_1477098200; Message-ID: <580ABCBD.6080401@emindsoft.com.cn> Date: Sat, 22 Oct 2016 09:11:25 +0800 From: Chen Gang User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andrew Morton CC: dhowells@redhat.com, linux-kernel@vger.kernel.org, Chen Gang Subject: Re: [PATCH] uapi: linux: acct: Remove redundant type comp2_t from kernel References: <1475674810-1560-1-git-send-email-chengang@emindsoft.com.cn> <20161020204122.2afc9264b4671add55112fe7@linux-foundation.org> <580A9C71.5020605@emindsoft.com.cn> In-Reply-To: <580A9C71.5020605@emindsoft.com.cn> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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@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.