From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751953AbdJEXS4 (ORCPT ); Thu, 5 Oct 2017 19:18:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57082 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbdJEXSz (ORCPT ); Thu, 5 Oct 2017 19:18:55 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9420AC04B954 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=swood@redhat.com Message-ID: <1507245534.2256.29.camel@redhat.com> Subject: Re: [PATCH 8/8] ktest: Use config-bisect.pl in ktest.pl From: Scott Wood To: Steven Rostedt Cc: linux-kernel@vger.kernel.org Date: Thu, 05 Oct 2017 18:18:54 -0500 In-Reply-To: <20171005085029.56ff06eb@gandalf.local.home> References: <20170717001630.10518-1-swood@redhat.com> <20170717001630.10518-8-swood@redhat.com> <20171004151832.512f774e@gandalf.local.home> <1507148663.2256.26.camel@redhat.com> <20171005085029.56ff06eb@gandalf.local.home> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 05 Oct 2017 23:18:55 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2017-10-05 at 08:50 -0400, Steven Rostedt wrote: > On Wed, 04 Oct 2017 15:24:23 -0500 > Scott Wood wrote: > > > It should also be noted that ktest.pl only depends on config- > > bisect.pl > > if a config bisect is being performed, so other ktest.pl functions > > still > > work standalone. > > I thought about this too, and may be able to live with that. Perhaps > we > should make the config-bisect internals into something that can be a > perl library, and be able to place that someplace that both could use? I'm not familiar with how Perl libraries work -- how would they solve this problem? If you're talking about having to install the library into some location outside the kernel tree, that seems contrary to the desire to have a lightweight tool that can be copied around. If not, how would it be any better than depending on a callable script? -Scott