From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 3FBAE475D for ; Thu, 29 Sep 2016 22:42:04 +0200 (CEST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 B384C89C36; Thu, 29 Sep 2016 20:42:03 +0000 (UTC) Received: from dhcp-25-97.bos.redhat.com (dhcp-25-172.bos.redhat.com [10.18.25.172]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u8TKg2kl011987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 29 Sep 2016 16:42:03 -0400 From: Aaron Conole To: Flavio Leitner Cc: dpdk References: <1474642051-9973-1-git-send-email-fbl@sysclose.org> <20160927183237.GA27384@plex> Date: Thu, 29 Sep 2016 16:42:02 -0400 In-Reply-To: <20160927183237.GA27384@plex> (Flavio Leitner's message of "Tue, 27 Sep 2016 15:32:37 -0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 29 Sep 2016 20:42:03 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH] eal: check cpu flags at init X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Sep 2016 20:42:04 -0000 Flavio Leitner writes: > On Mon, Sep 26, 2016 at 11:43:37AM -0400, Aaron Conole wrote: >> My only concern is whether this change would be considered ABI >> breaking. I wouldn't think so, since it doesn't seem as though an >> application would want to call this explicitly (and is spelled out as >> such), but I can't be sure that it isn't already included in the >> standard application API, and therefore needs to go through the change >> process. > > I didn't want to change the original behavior more than needed. > > I think another patch would be necessary to change the whole EAL > initialization because there's a bunch of rte_panic() there which > aren't friendly with callers either. Okay makes sense. Acked-by: Aaron Conole