From owner-freebsd-hackers@FreeBSD.ORG Tue Dec 9 16:45:28 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE0DE1AE; Tue, 9 Dec 2014 16:45:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 714F4DDD; Tue, 9 Dec 2014 16:45:28 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id sB9GjGW4030174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Dec 2014 18:45:16 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua sB9GjGW4030174 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id sB9GjGha030172; Tue, 9 Dec 2014 18:45:16 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Dec 2014 18:45:16 +0200 From: Konstantin Belousov To: Stefan Esser Subject: Re: [Patch] updated: Add JSON and XML output to pciconf (libxo support - D1206) Message-ID: <20141209164516.GB97072@kib.kiev.ua> References: <201412082114.sB8LEJnR056654@idle.juniper.net> <548723D0.1000402@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <548723D0.1000402@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "freebsd-hackers@freebsd.org" , Phil Shafer X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Dec 2014 16:45:29 -0000 On Tue, Dec 09, 2014 at 05:31:12PM +0100, Stefan Esser wrote: > Am 08.12.2014 um 22:14 schrieb Phil Shafer: > > Stefan Esser writes: > >> D1206 on reviews.freebsd.org (https://reviews.freebsd.org/D1206). > > > > Patch looks good. Some nits: > > Hi Phil, > > thanks again for your effort to help me understand libxo! > > > The names for xo_open_list and xo_open_instance need to be > > identical, so: > > > >> @@ -554,9 +698,14 @@ > >> /* Walk the capability list. */ > >> express = 0; > >> ptr = read_config(fd, &p->pc_sel, ptr, 1); > >> + xo_open_list("capabilities"); > > > > should be: > > > > xo_open_list("capability"); > > > > to match: > > > >> + xo_open_instance("capability"); > > I just re-read the man-page for xo_list_open() and it clearly says: > > "The name given to all calls must be identical, and it is strong > suggested that the name be singular, not plural, [...]", which I had > wrongly understood to only relate to opening and closing of elements. If it is required that the name be identical, it makes more sense to require some handle to be passed to functions instead of the string. I.e. either there should be some atom-like calls which convert string to identifier, or first call should return handle passed to consequent calls. This is obviously a note WRT libxo interface, not your patch. > > I had noticed, that the parameter of xo_open_list() is printed as > the array name in JSON, while the parameter of xo_open_instance() is > used as the element name in XML - it seemed more natural to use the > plural for the array name ... (and I had not noticed the sentence I > quoted above). > > > Similar for: > > > >> + xo_open_list("extended-capabilities"); > >> ... > >> + xo_open_list("error-categories"); > >> ... > >> + xo_open_list("base-addresses"); > > Yes, there were even more, I have fixed them in my local version > (not yet uploaded to the reviews site). .... > OTOH, I'd love to see the output generated on an AMD64 system > with HyperThreading information. There are no AMD processors which support HyperThreading. I suspect you mean HyperTransport there. Any relatively modern AMD CPU, in particular, all chips capable of running amd64, use hypertransport for northbridge. Look at netperf cluster for available resources, there are several AMD machines there https://wiki.freebsd.org/TestClusterOneReservations