From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [PATCH kvm-unit-tests] cscope: fix database generation Date: Wed, 20 Apr 2016 10:31:24 -0400 Message-ID: References: <20160419052510.t2xkdunwjmwvry77@hawk.localdomain> <20160419183845.GB10102@potion.brq.redhat.com> <20160419192228.GA25335@potion> <20160420084355.ozvxntl2v3dkjymo@hawk.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Radim =?utf-8?B?S3LEjW3DocWZ?= , KVM , Paolo Bonzini To: Andrew Jones Return-path: Received: from mx1.redhat.com ([209.132.183.28]:55948 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754312AbcDTOb1 convert rfc822-to-8bit (ORCPT ); Wed, 20 Apr 2016 10:31:27 -0400 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 15EBA201FA for ; Wed, 20 Apr 2016 14:31:27 +0000 (UTC) In-Reply-To: <20160420084355.ozvxntl2v3dkjymo@hawk.localdomain> (Andrew Jones's message of "Wed, 20 Apr 2016 10:43:55 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Andrew Jones writes: > On Tue, Apr 19, 2016 at 03:44:50PM -0400, Bandan Das wrote: >> Radim Kr=C4=8Dm=C3=A1=C5=99 writes: >>=20 >> > 2016-04-19 14:58-0400, Bandan Das: >> >> Radim Kr=C4=8Dm=C3=A1=C5=99 writes: >> >>> 2016-04-19 13:08-0400, Bandan Das: >> >>>> Andrew Jones writes: >> >>>>> On Mon, Apr 18, 2016 at 07:04:55PM -0400, Bandan Das wrote: >> >>>>>>=20 >> >>>>>> The cscope.files that we generate doesn't include all >> >>>>>> source files that are potentially interesting. We should >> >>>>>> include all $(ARCH)es and not the just the one configure >> >>>>>> finds. Moreover, $(ARCH) expands to x86_64 which is not the >> >>>>>> correct path for x86 sources. Generate cscope.files by search= ing >> >>>>>> for all files starting from root. >> >>>>> >> >>>>> No thanks :-) I'd rather not get hits for x86 and powerpc when >> >>>>=20 >> >>>> I don't think that's a good idea. Just because you don't like t= o >> >>>> see x86 bits when jumping around in arm code doesn't mean you s= hould >> >>>> hide all references to a given function. And if the arm code is >> >>>> segregated enough that there are no common functions, you won't >> >>>> see them anyway.=20 >> >>>> [...] But please = let's >> >>>> not make it difficult to write arm/powerpc tests just because s= omeone's on >> >>>> x86 :) > > How does it make it more difficult to write arm/powerpc tests on x86? > I do it all the time. Of course you need to run ./configure --arch=3D= > first, but you need to do that to compile anyway. > >> >>> >> >>> In the kernel, environment can override configuration, so you'd = do >> >>> >> >>> % ARCH=3Darm make cscope >> >>> >> >>> and it doesn't matter what arch is being compiled. I think this= would >> >>> be a better solution for kvm-unit-tests too. > > This is what kvm-unit-tests does, except it takes ARCH from config.ma= k, > instead of making you specify it, and there is no 'everything' option= , > default or otherwise right now. > >> >>> >> >>> I agree with Drew that other arches would mostly clutter searche= s if >> >>> they were included by default, but we can also add a rule in cas= e >> >>=20 >> >> Since you mentioned the kernel, it looks like both the kernel/qem= u >> >> include all by default which makes sense to me. >> > >> > qemu does, kernel doesn't (e.g. search for sys_sigreturn). >>=20 >> Not exactly, arch specific(arch/*) files are excluded but there are >> others such as sound/* include/* that are not all x86 specific. The >> arch segregation is helpful since there would be functions with simi= lar >> names (and similar functionality). That's not the case for every fil= e >> in x86/ and arm/ of kvm-unit-tests. > > kvm-unit-tests' cscope find collects all common files and all arch > specific files, just as you've described about the kernel. Please giv= e > an example of where you couldn't find something you needed with this > find, so that I know what the problem is. Also, if there is a problem= , Sorry, you are right. Looks like I was looking at stale files (iotable.= c/h) which don't exist anymore. So, I think the current setup works for me too since I mostly work on x86. For other times, when I do have to cert= ain things in other arches, I will just run cscope by hand. > we can likely extend the find just a bit, rather than changing it to = a > wholesale search. > >>=20 =2E.. >>=20 >> Yes, the option is definitely nice but making it the default, not so= much. > > As should be clear by now, IMHO, the default is not only nice, but co= rrect. > Feel free to add a cscope-all target though. Yeah, I can live with this too. IMHO, the default is a matter of prefer= ence, there's no question of correctness. >>=20 >> > (I don't care about the default much, `ARCH=3D$sth make cscope` is= easy >> > to type if the default included all.) > > I can live with that too, but I do care about defaults, and defaults > should target the common cases. I haven't yet seen enough justificati= on > as to why seeing everything (whether you want to or not) is the best > common case for kvm-unit-tests' cscope generation. Me neither, I am not convinced yet how including all files obstructs yo= ur workflow but I am certain living with the defaults won't obstruct mine. > Thanks, > drew