From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bandan Das Subject: Re: [PATCH kvm-unit-tests] cscope: fix database generation Date: Tue, 19 Apr 2016 15:44:50 -0400 Message-ID: References: <20160419052510.t2xkdunwjmwvry77@hawk.localdomain> <20160419183845.GB10102@potion.brq.redhat.com> <20160419192228.GA25335@potion> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Andrew Jones , KVM , Paolo Bonzini To: Radim =?utf-8?B?S3LEjW3DocWZ?= Return-path: Received: from mx1.redhat.com ([209.132.183.28]:59518 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbcDSTow convert rfc822-to-8bit (ORCPT ); Tue, 19 Apr 2016 15:44:52 -0400 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (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 981553D6 for ; Tue, 19 Apr 2016 19:44:51 +0000 (UTC) In-Reply-To: <20160419192228.GA25335@potion> ("Radim \=\?utf-8\?B\?S3LEjW0\=\?\= \=\?utf-8\?B\?w6HFmSIncw\=\=\?\= message of "Tue, 19 Apr 2016 21:22:28 +0200") Sender: kvm-owner@vger.kernel.org List-ID: Radim Kr=C4=8Dm=C3=A1=C5=99 writes: > 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 searching >>>>>> 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 to >>>> see x86 bits when jumping around in arm code doesn't mean you shou= ld >>>> 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 some= one's on >>>> x86 :) >>> >>> 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 wo= uld >>> be a better solution for kvm-unit-tests too. >>> >>> I agree with Drew that other arches would mostly clutter searches i= f >>> they were included by default, but we can also add a rule in case >>=20 >> Since you mentioned the kernel, it looks like both the kernel/qemu >> include all by default which makes sense to me. > > qemu does, kernel doesn't (e.g. search for sys_sigreturn). 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 similar names (and similar functionality). That's not the case for every file in x86/ and arm/ of kvm-unit-tests. > >> As I mentioned above= , >> you definitely don't want to modify a common library function only t= o >> realize that you forgot to modify all sites. Looking at all sites ad= ds >> visibility, not introduce clutter. >>=20 >>> indexing all arches is desired (like when changing the prototype of= some >>> generic function?). >>=20 >> kvm-unit-tests is small enough that this can be the default. > > I don't see a reason to add results that we'd then have to mentally > filter regardless of their amount. > >> That sa= id, this >> is a trivial change and I am happy to live with it in my local branc= h. (Unless >> ofcourse both Linux and Qemu decide to make this default behavior to= o!) > > I think we'll agree on something that can be merged -- the present > situation is bad. It's not that bad, actually. We are simply arguing over personal preferences here. Changing my workflow a bit is not hard. :) > For me, "include all" is a matter of `cscope -bk **/*.[chS]` and gett= ing > only arch-specific cscope is harder, so having an option to generate > cscope just for target arch would be nice. Yes, the option is definitely nice but making it the default, not so mu= ch. > (I don't care about the default much, `ARCH=3D$sth make cscope` is ea= sy > to type if the default included all.) > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html