From owner-freebsd-current@freebsd.org Tue Nov 17 00:31:09 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B2EFEA3131E for ; Tue, 17 Nov 2015 00:31:09 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 3910D1185 for ; Tue, 17 Nov 2015 00:31:08 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190f-f79d06d000004b20-1a-564a74172c46 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id B5.22.19232.7147A465; Mon, 16 Nov 2015 19:25:59 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id tAH0PwBm014040; Mon, 16 Nov 2015 19:25:58 -0500 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tAH0PttL009021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Nov 2015 19:25:57 -0500 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id tAH0PseH014087; Mon, 16 Nov 2015 19:25:54 -0500 (EST) Date: Mon, 16 Nov 2015 19:25:54 -0500 (EST) From: Benjamin Kaduk To: Warner Losh cc: Justin Hibbits , FreeBSD Current Subject: Re: CFT: uintmax_t rman In-Reply-To: <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> Message-ID: References: <75C2B97F-3C5E-49E3-A584-DE84463889FC@gmail.com> <0F3B8FF2-E54E-446F-8D4E-415A1111EF4D@bsdimp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUixCmqrCte4hVmcG6DtMWVvdtYLOa8+cBk 8XTrckYHZo8Pu7+yesz4NJ/FY+esu+wBzFFcNimpOZllqUX6dglcGf3nZ7IVvBOoeNGygqWB 8SJvFyMnh4SAicTUlWeZIWwxiQv31rN1MXJxCAksZpKYe/MOE4SzkVFi8e+pUM4hJomP24+z QzgNjBJz1t9mBelnEdCWODrtPNgsNgEViZlvNrKB2CICChKrjtxlAbGZBRIlujf1s4PYwkDx X6eXg9VwCthJbF/1CqyGV8BRYs7dbiYQW0ggT2LBxalgtqiAjsTq/VOgagQlTs58AjUzUOLG tXOsELajxIcXr5gnMArNQlI2C0nZLCRlELaOxM0Zi9kgbG2J+zfbgGwOsJoF6yoXMLKtYpRN ya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECI4bSf4djN8OKh1iFOBgVOLhbfjrGSbE mlhWXJl7iFGSg0lJlFeh0CtMiC8pP6UyI7E4I76oNCe1+BCjBAezkggvVwRQjjclsbIqtSgf JiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgvd2EVCjYFFqempFWmZOCUKaiYMTZDgP 0PCNIDW8xQWJucWZ6RD5U4yKUuK8S0ESAiCJjNI8uF5wWtvNpPqKURzoFWFeg2KgKh5gSoTr fgU0mAlo8IkGT5DBJYkIKakGxirO1usMAVK9f0Mf2Wrqp6/QqAxk7HjxMdZA9MDX7y1fj/uW WGSJ2s55FLjkwv3QH25WjE//zlGYaHl5TaPOv7Psh0QVyv32Lzt8Sn/F8vvW3wNnbDL8WifU O/HjIqGtO1w7Dn22Ko/3Xn99ilz4BBe1dkEBdcam9c/3sIjf3fSxVW29CN+6uUosxRmJhlrM RcWJAKoKwxdGAwAA Content-Type: TEXT/PLAIN; charset=ISO-8859-7 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 00:31:09 -0000 On Mon, 16 Nov 2015, Warner Losh wrote: > > > > On Nov 15, 2015, at 9:13 PM, Justin Hibbits wrot= e: > > > > (Attempted to send this yesterday, but appears it didn't go through. A= pologies if it really did go through). > > > > As part of a project getting FreeBSD on the Freescale P5020 SoC, I incr= eased the width of resources, from u_long(32 bits on 32-bit archs, 64 bits = on 64-bit archs) to uintmax_t (currently 64 bits on all archs). I have it = working on PowerPC, but have not tested it on any other architecture, I hav= e no other systems to test it with, so I need help. This passes a tinderbo= x build. I need this tested on other archs, the more the better, especiall= y i386, including PAE. > > > > It should be effectively a no-op on most architectures, especially 64-b= it archs, though there were some checks I found in x86 code clamping addres= s checks to under 4GB, commented as necessary purely for rman. If this isn= 't the case, and we can't yet handle the checks being removed, they can go = in, but that needs testing. It should apply cleanly to recent head. > > I like the idea. There=A2s nothing offensive enough in the diffs to comme= nt upon here (though I suppose I could see a few spots one could quibble ov= er if one were so inclined). > > I wonder, though, why not make its own typedef, even if it is just > =A1typedef man_res_t uintmax_t;=A2 in the rman headers? Channeling my inner bde (maybe?), the typedef is probably helpful, but uintmax_t seems less so. uintmax_t has no guaranteed ABI, so a fixed-width type like uint64_t seems beter, assuming that uintmax_t is currently uint64_t everywhere (which I think is the case but did not verify). -Ben From owner-freebsd-current@freebsd.org Tue Nov 17 02:13:22 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CF31A30E54 for ; Tue, 17 Nov 2015 02:13:22 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 635141303; Tue, 17 Nov 2015 02:13:22 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from Alfreds-MacBook-Pro-2.local (unknown [IPv6:2601:645:8004:7515:6d56:aa8e:b437:27b3]) by elvis.mu.org (Postfix) with ESMTPSA id A601D345A921; Mon, 16 Nov 2015 18:13:16 -0800 (PST) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: Allan Jude , freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <702A1341-FB0C-41FA-AB95-F84858A7B3A4@rdsor.ro> <5648C60B.6060205@freebsd.org> <6EDFB74B-2206-46E7-85F7-8DE05FB6D325@gmail.com> <5648CA60.3060800@freebsd.org> From: Alfred Perlstein Organization: FreeBSD Message-ID: <564A8D3C.2080900@freebsd.org> Date: Mon, 16 Nov 2015 18:13:16 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <5648CA60.3060800@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Nov 2015 02:13:22 -0000 On 11/15/15 10:09 AM, Allan Jude wrote: > On 2015-11-15 13:06, Garrett Cooper wrote: >>> On Nov 15, 2015, at 09:51, Andrey Chernov wrote: >>> >>>> On 15.11.2015 20:37, Adrian Chadd wrote: >>>>> On 15 November 2015 at 09:10, Dan Partelly wrote: >>>>> Meaning, is that simple to push things in head , if somone does the work, even with with no proper review of the problem at hand , and the proposed solutions ? >>>> Nope and yup. The juniper folk had a solution to a problem multiple >>>> people had requested work on, and their proposal was by far the >>>> furthest along code and use wise. >>>> >>>> It's all fine and good making technical decisions based on drawings >>>> and handwaving and philosophizing, but at some point someone has to do >>>> the code. Juniper's libxo was the furthest along in implementation and >>>> production. >>> It seems it is the only and final argument for libXO existence. I >>> remember 2 or 3 discussions against libXO spontaneously happens in the >>> FreeBSD lists, all ended with that, approximately: "we already have the >>> code and you have just speculations". Alternative and more architecture >>> clean ideas, like making standalone template-oriented parser probably >>> based on liXO, are never seriously considered, because nobody will code >>> it, not for other reasons. >> We lack a [dtd/json] spec for tools, so programming for xo'ification doesn't seems like the best idea in the world to me from a end-user sysadmin/developer perspective. >> >> I could just as easily use standard tools like awk, grep, sed, and more advanced languages like perl or Python to parse output, and assuming output doesn't get a major rewrite, I'd just go with that method that's worked pretty well for me over the last 10 years of my career.. >> >> > The big difference is, a json parser isn't going to blow up if a new > field gets added in the middle, and your awk/grep/sed script probably will. > Alan is exactly correct. This is EXACTLY why it is important. It allows us to focus on the text UI without worrying about the 5000 tools built to parse the output of the utilities. It allows us to grow a useful text UI. Second is that parsing is as simple as doing "json2struct()" in whatever language you're using and then selecting a field as opposed to writing terrible regex. It's basically "libification" of the program without actual libification. Next step is to actually libify the programs. Libifying the programs would be VERY, VERY cool. But "libification" doesn't make json output not useful. -Alfred