From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751051AbcGMGjp (ORCPT ); Wed, 13 Jul 2016 02:39:45 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:23549 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750780AbcGMGjj (ORCPT ); Wed, 13 Jul 2016 02:39:39 -0400 X-IBM-Helo: d03dlp01.boulder.ibm.com X-IBM-MailFrom: gongss@linux.vnet.ibm.com Subject: Re: [PATCH] [RFC V1]s390/perf: fix 'start' address of module's map To: Jiri Olsa References: <1467856176-8712-1-git-send-email-gongss@linux.vnet.ibm.com> <20160708152133.GK31763@krava> <657df05c-c0d9-7490-d374-f2fa4cdd7344@linux.vnet.ibm.com> <20160711120155.GA29929@krava> Cc: acme@kernel.org, jolsa@kernel.org, dsahern@gmail.com, linux-kernel@vger.kernel.org From: Songshan Gong Date: Wed, 13 Jul 2016 14:39:13 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160711120155.GA29929@krava> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16071306-0008-0000-0000-0000050B1500 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16071306-0009-0000-0000-00003943962A Message-Id: <6aba748e-0669-34e0-b056-4a76ed141c08@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-07-13_01:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607130073 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 7/11/2016 8:01 PM, Jiri Olsa 写道: > On Mon, Jul 11, 2016 at 07:06:14PM +0800, Songshan Gong wrote: > > SNIP > >>> >>> we have following functions in tools/lib/api/fs to read >>> single number from file, which I assume you do above: >>> >>> int sysfs__read_int(const char *entry, int *value); >>> int sysfs__read_ull(const char *entry, unsigned long long *value); >>> >>> please check if you could use some of them, >>> we could add some more generic one if needed >> >> It seems infeasible. >> Each value in /sys/module/[module name]/sections/.text is a string like >> "0x000003ff8130078\n". >> But the core function 'strtoull(line, NULL, 10)' in sysfs__read_ull is based >> on decimal. >> >> Maybe you can introduce a new argument indicating the value is based on hex >> or decimal, or binary? > > yea we could specify it directly and add something like: > > int filename__read_ull(const char *filename, unsigned long long *value, int base) > > plus some other higher layer helpers.. > > but I wonder if we could use the base 0 (like in the attached patch), > the man page says it should be able to detect the base > > we'd need to check all the current usage to make sure nothing gets broken > > jirka > > Since your patch havn't pushed to devel branch, my next version patch will still use the origin method to parse value from /sys/. Thanks. > --- > diff --git a/tools/lib/api/fs/fs.c b/tools/lib/api/fs/fs.c > index 08556cf2c70d..d18ae548468a 100644 > --- a/tools/lib/api/fs/fs.c > +++ b/tools/lib/api/fs/fs.c > @@ -292,7 +292,7 @@ int filename__read_ull(const char *filename, unsigned long long *value) > return -1; > > if (read(fd, line, sizeof(line)) > 0) { > - *value = strtoull(line, NULL, 10); > + *value = strtoull(line, NULL, 0); > if (*value != ULLONG_MAX) > err = 0; > } > -- SongShan Gong