From owner-freebsd-hackers@freebsd.org Sat Oct 19 16:35:38 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EDF3015129B for ; Sat, 19 Oct 2019 16:35:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 46wT6L40Jvz4Q0J for ; Sat, 19 Oct 2019 16:35:38 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1571502937; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Xz7MfoaapQVgTxYUUf1uMDEEzAwynKq6X24TuyF3GEPwdm3x6Si6IjK8v5+wmIjE0Y/gDumRXVUu8 i6knbG0qmcrYLyYdaR835Y28mfvnC756gyyacXT/oDS81VAEbSoUqWxhS6u+xoZovMUlrnJOjusFKa snSFjxfbmZqqsIUQuiQ3VbRTKgpldOlmTsSFeQYUkkW0IM1rHbdYbv3N36+YLovP0LN66u5lDII4Dl 3MdHijlntdBW0ggaRS2ubPFtY57fwmZpWmxVASxgTqoZZSZMTmtGJjAbvB09CtW3/0MxF8GpaeB51P PtGgEzCN9I52ivGZnoyyEovqMNtwv/Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:dkim-signature:from; bh=KPtj4+lFXV19wOmkes+b0Z0s0L9h/idVv+Wha67l3qk=; b=dabn62Wrm26I9y0KpoRiUOhQeVDpZWtC5nVHJ5OPhDaKTHk1HkKBzK3iOgLivCBKOg8nvC468nU+e 89xYO4q0NMof2z4k881D+9bB6g6aRIip7lbtuBEVjJnGiGuoa84k10GIvv5z09Dkp9W110pHJeecuP y85kTHOxvt2T9DG2YP4viknKfcwSwECru0PmSJ6Xz9aCoFX5yXOzHndvS2wFcYHwrjsW5n3y3oqZXz QF59LZkMQ1h2TH9yCx/fpnz+/WzqYQg2zbz3DpsTc4mawPQUYCqXwOvS2oczxgV4JLxIUu8qkWrIT/ nDv/x4SquZmsAUA6lkXGw9MrDqUtJVw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:to:from:subject:message-id:from; bh=KPtj4+lFXV19wOmkes+b0Z0s0L9h/idVv+Wha67l3qk=; b=pZga06o5yd4rhDHfE/cfn+l502JBQuFTWl++d8qTP5EzJTwBVayM4c63BSLM0JD/TUKLtzb7qIlif 5HR/4XR/JwRjY7q1QaGkB3s2xiEG/9PwsyXleXb3V7Ygg4Q9hB5Z4m41Mr3lf0RMCozuuy2diF2pND MT1Cl9Y3zx88ZQYJrzHBxPmbs0VbfSDZLLBso6GLqNiGLaki57XFq+Um7ZbmQT1dG3JZ2QDxrGafrh Lok8t06zoqGvwJE9b/FK/wF9ga+niSG1M9bCx+BEmy8biIqRVRGcAkfSFmI9EGUkAj9pevDQsUHoTB pxz07eU5NBTmNUyYPylSNrMWYjxjTeQ== X-MHO-RoutePath: aGlwcGll X-MHO-User: 77e2e801-f28e-11e9-85ed-13b9aae3a1d2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 77e2e801-f28e-11e9-85ed-13b9aae3a1d2; Sat, 19 Oct 2019 16:35:35 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x9JGZVwd025839; Sat, 19 Oct 2019 10:35:32 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <89cc36381cd82b81b8664f701c63a96724d3f881.camel@freebsd.org> Subject: Re: sysctl questions From: Ian Lepore To: Milan Obuch , freebsd-hackers@freebsd.org Date: Sat, 19 Oct 2019 10:35:31 -0600 In-Reply-To: <20191019134524.3cc3d274@zeta.dino.sk> References: <20191019134524.3cc3d274@zeta.dino.sk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 46wT6L40Jvz4Q0J X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.87 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.87)[-0.869,0]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Oct 2019 16:35:39 -0000 On Sat, 2019-10-19 at 13:45 +0200, Milan Obuch wrote: > Hi, > > I am working on AXI XADC driver on Zynq based Zybo Z7 board. I created > simple PL design to be able to use this core IP. Looking in some other > ADC driver I desided to use sysctl API to report measurements. So I did > create mib entry in attach function like this > > snprintf(pinbuf, sizeof(inum), "%d", i); > > inpN_node = SYSCTL_ADD_NODE(ctx, inp_tree, OID_AUTO, inum, > CTLFLAG_RD, NULL, "ADC input"); > inpN_tree = SYSCTL_CHILDREN(inpN_node); > > SYSCTL_ADD_PROC(ctx, inpN_tree, OID_AUTO, "read", > CTLFLAG_RD | CTLTYPE_UINT, &axi_xadc_inputs[i], 0, > axi_xadc_read_proc, "IU", "Read ADC input"); > > where inum is string, i is integer - input number. Top node for my > mib entries is dev.adc.0.ain. When the above snippet is run for i from > 0 up to Ninputs - 1, sysctl shows them in opposite order, i. e. > > # sysctl dev.adc.0.ain > dev.adc.0.ain.3.read: > dev.adc.0.ain.2.read: > dev.adc.0.ain.1.read: > dev.adc.0.ain.0.read: > > Why it is so? It looks for me a bit counter intuitive, I like the nodes > be ordered the way I decide, not the other way so... so I am just > calling the initialisation snippet for i starting with Ninput - 1 down > to 0 and it works the way I want. > The sysctl oid entries are stored in an SLIST and each new entry is added to the head of the list, so when sysctl(8) walks the list of children of a given oid, they get displayed in reverse order of how they were added. > Other thing I do not understand is my axi_xadc_read_proc is called > *twice* per node. My procedure is short: > This happens because sysctl(8) makes two calls per value retrieved. The first call has req->oldptr set to NULL which makes the sysctl machinery return the length of the return value without returning the value itself. Sysctl(8) then allocates a buffer of the right length and makes another call with req->oldptr pointing to the allocated buffer to actually retrieve the value. When there is some cost to returning the value (such as an expensive or time-consuming hardware operation), you can check whether oldptr is NULL or not before doing the expensive work. For an example, see the ads111x_sysctl_voltage() function in sys/dev/iicbus/ads111x.c -- Ian