From owner-freebsd-arch@freebsd.org Mon Feb 22 01:42:50 2016 Return-Path: Delivered-To: freebsd-arch@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 7ADD3AB0247 for ; Mon, 22 Feb 2016 01:42:50 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3ECF61750 for ; Mon, 22 Feb 2016 01:42:50 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x234.google.com with SMTP id gc3so151648690obb.3 for ; Sun, 21 Feb 2016 17:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7wJLdm/IFW50/TF6yFJ9eAhH31bCuO39UoelMNJIx6A=; b=FNdsT7DR/mGt9d6It77eX/l5kUjfZD1itNiGB2tO5RcESxI0uBKqO8KDqMg+dDzD0S H1ViFTqqta/fuMeIstVRXgtknMh1y75eKFTfp+tqhnLiJE20gNKTajmq4UMqpKIFE8yB j6TpDX6HQ5xnpwZwcDobVA7oJBEkyFX9UHGIPdqyvvCrQkpfoWO5KmDPBtkgttEA8NNk ig4ZW7IP0McTqhbAyakRaz5s9fhOQTN6a9Yrq5RSlyUn9v2vJTlRBlqj/Se27OCleyCl 79MUqVHrSQFi7CdujXDspenJ/hHc7dDAZKjC8jeKOmExZwF38M7/X398FHJBpr4WTQ66 1LwQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=7wJLdm/IFW50/TF6yFJ9eAhH31bCuO39UoelMNJIx6A=; b=UEV6hGzxTd4YtffcGapXQ2EfYWGZsCrP7SsEQGqloULKhQ72OsNVAWBkJZKyvVdARt lNTGATnsVwk7Oa/7NWMqBPTFiQ5+K+/okm9CG6zr2l/3LpE6KVglx8Yie3SJrGrw0jEo ux0b/gCnv/EiXO/+DjG9s59MJ4aOdoksZPaQk0RUyCvtDLjcPcHfFMRodO7DA9uNpyCl Mkurjq4FtBv9nLshGEdFpTabuNE3+cXP6k/QxBfgPG6iL+6+3GpV9259XwMWFukPn9yD tt61gfrr5atiOIcNDBEEfMP7+l0wOEwXmAbVt+7LPbinVEx1ETpsH8nLB1ZzhUf7e0vd Sqmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:date:message-id:subject:from :to:content-type; bh=7wJLdm/IFW50/TF6yFJ9eAhH31bCuO39UoelMNJIx6A=; b=ZTTjmE3PD0h5Egw6Modh/bnYkePdOsuk3C/SWujBLP6TyGC9D4g4oPltX5y9L+qXWQ CpAMYE6NwrGrFalJoy8/wbDM68fU8rN6IIZ6MAxoNJQfXmqN+BBNnNkKYHzxwt+ak+vY gCeIFylMuJ/u5jpbPDCYCG4t3lADeQ/JZ79QLUGwARdWTR4lG5F8rFTGvZrn+ScyWRvh h2FVx4zKz58CW2r+LVLhxAutt8kvNmLvMNHdOSFggrPa1Si0nJbrHImLxt4DI2bdi4m1 LatPnpcyy4YncoqtNXkmSfuN00f31yP+9sNHhgUJDhGFFStPWJFNo6A//WT1QezznjpH 0X7g== X-Gm-Message-State: AG10YOTQ706tSZ3BZUCh8vlXpKqu4DqrFwTkC9x3Aqu2dwvCzMEy+MtG0mJtbA0uPFCoGTF1SmR1hN68NG4lTw== MIME-Version: 1.0 X-Received: by 10.60.83.98 with SMTP id p2mr5878495oey.16.1456105369409; Sun, 21 Feb 2016 17:42:49 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Sun, 21 Feb 2016 17:42:49 -0800 (PST) Date: Sun, 21 Feb 2016 19:42:49 -0600 X-Google-Sender-Auth: OnnWK22CRiJTmUqbLKEBPVrLyY8 Message-ID: Subject: RF_CACHEABLE flag From: Justin Hibbits To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 01:42:50 -0000 The Freescale/NXP Datapath Acceleration Architecture uses both cache-inhibited and cache-enabled memory regions for buffer portals. This doesn't quite fit right into the existing framework, so I've added to my personal repo (on github) a RF_CACHEABLE flag to be used by this. Now that I'm ready to commit the driver to head, I want to float this on -arch to get opinions. I did consider another route, using bus_space_map()/bus_space_unmap(), and stashing sizes around, but adding a simple flag to rman would take care of all the details, and rman already knows all the other details for the region anyway. I put the diff on phabricator, at https://reviews.freebsd.org/D5384 . Thoughts on this? - Justin From owner-freebsd-arch@freebsd.org Mon Feb 22 12:19:10 2016 Return-Path: Delivered-To: freebsd-arch@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 339DDAB0992 for ; Mon, 22 Feb 2016 12:19:10 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB6B81CB0 for ; Mon, 22 Feb 2016 12:19:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1MCIbMK097524 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 22 Feb 2016 14:18:37 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1MCIbMK097524 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1MCIalI097523; Mon, 22 Feb 2016 14:18:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 22 Feb 2016 14:18:36 +0200 From: Konstantin Belousov To: Justin Hibbits Cc: "freebsd-arch@freebsd.org" Subject: Re: RF_CACHEABLE flag Message-ID: <20160222121836.GH91220@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 12:19:10 -0000 On Sun, Feb 21, 2016 at 07:42:49PM -0600, Justin Hibbits wrote: > The Freescale/NXP Datapath Acceleration Architecture uses both > cache-inhibited and cache-enabled memory regions for buffer portals. > This doesn't quite fit right into the existing framework, so I've > added to my personal repo (on github) a RF_CACHEABLE flag to be used > by this. Now that I'm ready to commit the driver to head, I want to > float this on -arch to get opinions. > > I did consider another route, using bus_space_map()/bus_space_unmap(), > and stashing sizes around, but adding a simple flag to rman would take > care of all the details, and rman already knows all the other details > for the region anyway. > > I put the diff on phabricator, at https://reviews.freebsd.org/D5384 . > > Thoughts on this? Not making any opinion about RF_CACHEABLE, only pointing out some facts that might be interesting to you. On x86, some BARs need specific memory access modes at least for performance. E.g., for Intel GPUs, there is a combined BAR where the first 512KB or 2M maps the registers and must be uncacheable, and the rest of the BAR maps GTT. To get a reasonable performance from the graphics hardware, GTT should be mapped as write-combining (i.e. not cacheable but writes may sit in the combining buffers and flushed on serialization points). Look at dev/agp/agp_i810.c:agp_gen4_install_gatt() to see direct pmap_change_attr(WC) call to set it up. No flag could accomodate this mode. OTOH, why couldn't you explicitely add pmap_change_attr() to the driver of your device ? From owner-freebsd-arch@freebsd.org Tue Feb 23 20:19:58 2016 Return-Path: Delivered-To: freebsd-arch@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 CE450AB134B for ; Tue, 23 Feb 2016 20:19:58 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8A62F1C2D for ; Tue, 23 Feb 2016 20:19:58 +0000 (UTC) (envelope-from chmeeedalf@gmail.com) Received: by mail-ob0-x232.google.com with SMTP id jq7so206922044obb.0 for ; Tue, 23 Feb 2016 12:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G5BGM+wvYPQ/UDLb7klTf+sFO6sZuQpQN64iAUwo93Q=; b=o9w/u+gk51oHOYd1K+68++lyFWWgLayevwKs4Ssho8WcK4n4LgJtoHAtN45x3lKBMb ggDuIXvo21/bnDR9JvX9mMUKWEWun2Fh5FIZEh5jFoSXrNi94NaymyoxI17ZRu6joJBp pZDGCPSxbK4hWqK9Uc4WFTnJJPT0VEE3X+PS6FZtmeYY3kAdxkz9Z0Lrpn6DBWKubNlk Li8JVEs9udV7bQWssVH3PetajIB7LGhVNIy4q0xSizyyw1Gvjpsc/9QZfas3LDn4PaHA GDhZEnELoypnbMIRgi70xDufnBPvdUKazFQcIrmVgsjSXVllhPHNjhfx700yOl2CiJgh M7IA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alumni-cwru-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=G5BGM+wvYPQ/UDLb7klTf+sFO6sZuQpQN64iAUwo93Q=; b=s668z0hgMv+vKbJHQ8aoX209Fnhm2I/TNKhVgwwZBjFjf0fU4k2beJGred5YTrNpxM Lv42br3V7dPzc6z3MzuYDqgyCyvqgTkZi1NeKhEwA7VUVOP3PnV6A57AenyeUXGJz/3K 9mjjFmNb4LmDWGGESsEMkLEkTfZ5ZmZa4omDQsecnYO1JpS+Rj3zoABbPsH9sbkWjTqi 1gP0jb4iDtvRIQa1zsZiLnZrZwWgv32REoJ8hdpKbcTq3aYFUZkb8AO1casoqiM+0QJx b7+uKUBqZpDn1mLBbS6wS01gDiCrcOyTk/W4vsEX6fWwFbktSWUZOC12e2EvhCzq7QbZ f7jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G5BGM+wvYPQ/UDLb7klTf+sFO6sZuQpQN64iAUwo93Q=; b=YfeFKnc9HZBudtVWUxPpQsLP11aZKxMyBvKHvXYG1HMkKOjhaa4WpIfKRzPjEhD/ZH 7Hj2eIq9U7C0CpZeegXfCIi/gNm8pm3Qn+8Z9N+DEdQo0KNvweHHL7TcbUQ1nEMkoCtj S0GhDzJcCy65S5inxV4yjnGyqiaSn1wTmByZ60B752rqUaMvltQUkk1bmep0BLphBF5g NMKLSy44m/eHKyXzcJZG0evLWThlVUBRi2yD9DD//0/B4HN1n7dtdoEfYH6d9/+H6nMu yyNRN2Fw5vi4IJQlbb2dMFghP0Gdwm6a5yJr5c5CRZAzIsmA3UxUZRVBwbb8/nJBMDU8 yepg== X-Gm-Message-State: AG10YOTO2aKaKxVQ/RGRrzbIgRYkrAKGE9XCFBuWuG+HOkLHDeb475Rye75TWbYONIToi1RK0NgCM/ndT7Hkgw== MIME-Version: 1.0 X-Received: by 10.60.128.163 with SMTP id np3mr3305408oeb.16.1456258797714; Tue, 23 Feb 2016 12:19:57 -0800 (PST) Sender: chmeeedalf@gmail.com Received: by 10.182.33.8 with HTTP; Tue, 23 Feb 2016 12:19:57 -0800 (PST) In-Reply-To: <20160222121836.GH91220@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> Date: Tue, 23 Feb 2016 14:19:57 -0600 X-Google-Sender-Auth: JECrNBcx1fAx1i32W-QCfH9M26U Message-ID: Subject: Re: RF_CACHEABLE flag From: Justin Hibbits To: Konstantin Belousov Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:19:58 -0000 On Mon, Feb 22, 2016 at 6:18 AM, Konstantin Belousov wrote: > On Sun, Feb 21, 2016 at 07:42:49PM -0600, Justin Hibbits wrote: >> The Freescale/NXP Datapath Acceleration Architecture uses both >> cache-inhibited and cache-enabled memory regions for buffer portals. >> This doesn't quite fit right into the existing framework, so I've >> added to my personal repo (on github) a RF_CACHEABLE flag to be used >> by this. Now that I'm ready to commit the driver to head, I want to >> float this on -arch to get opinions. >> >> I did consider another route, using bus_space_map()/bus_space_unmap(), >> and stashing sizes around, but adding a simple flag to rman would take >> care of all the details, and rman already knows all the other details >> for the region anyway. >> >> I put the diff on phabricator, at https://reviews.freebsd.org/D5384 . >> >> Thoughts on this? > > Not making any opinion about RF_CACHEABLE, only pointing out some facts > that might be interesting to you. On x86, some BARs need specific memory > access modes at least for performance. > > E.g., for Intel GPUs, there is a combined BAR where the first 512KB or > 2M maps the registers and must be uncacheable, and the rest of the BAR > maps GTT. To get a reasonable performance from the graphics hardware, > GTT should be mapped as write-combining (i.e. not cacheable but writes > may sit in the combining buffers and flushed on serialization points). > > Look at dev/agp/agp_i810.c:agp_gen4_install_gatt() to see direct > pmap_change_attr(WC) call to set it up. > > No flag could accomodate this mode. OTOH, why couldn't you explicitely > add pmap_change_attr() to the driver of your device ? Already mentioned this on IRC yesterday, but best for me to follow up here. This really isn't much different from bus_space_map() conceptually. The work involved is pretty much the same, and if this route is deemed the Wrong Way(TM), I'll go that route. Grepping through sys/, only x86 currently implements pmap_change_attr(), and arm has the declaration but no definition that I could see. Writing it wouldn't be difficult of course, there's just not much compelling case for it right now. But, yes, either of these alternatives are acceptable, and I had explored it. Seeing John Baldwin's comment on the phab review, it looks like he wants to go a different (parallel) direction. - Justin From owner-freebsd-arch@freebsd.org Wed Feb 24 10:28:05 2016 Return-Path: Delivered-To: freebsd-arch@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 B0D80AB29DC for ; Wed, 24 Feb 2016 10:28:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 31A4B8BB for ; Wed, 24 Feb 2016 10:28:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1OARtOJ005229 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 24 Feb 2016 12:27:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1OARtOJ005229 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1OARsv5005216; Wed, 24 Feb 2016 12:27:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 24 Feb 2016 12:27:54 +0200 From: Konstantin Belousov To: Justin Hibbits Cc: "freebsd-arch@freebsd.org" Subject: Re: RF_CACHEABLE flag Message-ID: <20160224102754.GK91220@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 10:28:05 -0000 On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: > This really isn't much different from bus_space_map() conceptually. > The work involved is pretty much the same, and if this route is deemed > the Wrong Way(TM), I'll go that route. > > Grepping through sys/, only x86 currently implements > pmap_change_attr(), and arm has the declaration but no definition that > I could see. Writing it wouldn't be difficult of course, there's just > not much compelling case for it right now. But, yes, either of these > alternatives are acceptable, and I had explored it. Seeing John > Baldwin's comment on the phab review, it looks like he wants to go a > different (parallel) direction. If this was not clear from my reply, I did not objected against RF_CACHEABLE, but was more to highlight weird needs of seemingly simple architecture, which are close to RF_CACHEABLE stuff. And, I think that architectures that care about caching modes, should do provide real pmap_change_attr() implementation. This might be important e.g. if drm is brought up on these platforms. From owner-freebsd-arch@freebsd.org Wed Feb 24 17:14:22 2016 Return-Path: Delivered-To: freebsd-arch@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 62FC6AB2D26 for ; Wed, 24 Feb 2016 17:14:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E0DD19A1 for ; Wed, 24 Feb 2016 17:14:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22f.google.com with SMTP id l127so52558587iof.3 for ; Wed, 24 Feb 2016 09:14:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5ZgVAFCHX8LdXCnMkKzhhtFhhabGRTl6EyGGFcpH6BI=; b=t/UT3GoUMFtFy166fONdfkTY1vunkLMEpBe2jyKnI6ebYV1alSIXXnOZWs1EpyLGwc hEwQ3K/OCdWj72EQP/8XqgFH3xtyLzYOlS4MBHXmLV2ThKNvFtuEipaH4P4BFlH3FxJo sCB5KKrz5Tda58LXkwDnfsXy600Au7t56uaqFU1bQi9dJZCzOFHkp/bXz2x9FYM4XUHU GRIeZt+ZCvp29fIY1UOCK7n24jzIKE6qndKAcParFkV4qkuocQx26YG+XBObcarbYslT R+GABAVSHvUOkkULFdjvLukUZRS2RaL3GBilcN8HqTxkvjRnkS4Ta+gUpZuyzoEbOy9p JKhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5ZgVAFCHX8LdXCnMkKzhhtFhhabGRTl6EyGGFcpH6BI=; b=EpeGohzY6B5JwSjSv3X4IyzkSlr3oqKsdel0WEU98izc1xRbNaaNrSumwrxS1B/Ime Xvk75APHpSaF4pcbXB7sS7JWa9kAEF9Le2/sDXz3fnkXQg50KJ67tdqOLls6+M3yXAbA Ws1dmnFccFd/3iVx4mp3OilRAZmR5q1+CwbkdGyf1SnGbZZ79dJCsbS6Jg9jZPFpZhdz 8IWenMZoDiHkpa7x+dG6VGQqPOJ+xhjqNymW7pmEp4wximWJwyl8+X4ukhUG5CzoBs+W MfatUTmDuk7oVECiGoKN1xUZIPSO33vFIpvAPZ6AxYPjHMiwiowaie+7FvfgCXMz9pQI 9BBg== X-Gm-Message-State: AG10YOTCUu92T0CcvaWMSSbFcItB0j8OBcc42Oc223xIIt5dHjAOn6pZjsiCQCDoql8Npfk59tUaW6cGbQeSpw== MIME-Version: 1.0 X-Received: by 10.107.11.231 with SMTP id 100mr37611277iol.165.1456334057740; Wed, 24 Feb 2016 09:14:17 -0800 (PST) Received: by 10.36.14.19 with HTTP; Wed, 24 Feb 2016 09:14:17 -0800 (PST) In-Reply-To: <20160224102754.GK91220@kib.kiev.ua> References: <20160222121836.GH91220@kib.kiev.ua> <20160224102754.GK91220@kib.kiev.ua> Date: Wed, 24 Feb 2016 09:14:17 -0800 Message-ID: Subject: Re: RF_CACHEABLE flag From: Adrian Chadd To: Konstantin Belousov Cc: Justin Hibbits , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:14:22 -0000 On 24 February 2016 at 02:27, Konstantin Belousov wrote: > On Tue, Feb 23, 2016 at 02:19:57PM -0600, Justin Hibbits wrote: >> This really isn't much different from bus_space_map() conceptually. >> The work involved is pretty much the same, and if this route is deemed >> the Wrong Way(TM), I'll go that route. >> >> Grepping through sys/, only x86 currently implements >> pmap_change_attr(), and arm has the declaration but no definition that >> I could see. Writing it wouldn't be difficult of course, there's just >> not much compelling case for it right now. But, yes, either of these >> alternatives are acceptable, and I had explored it. Seeing John >> Baldwin's comment on the phab review, it looks like he wants to go a >> different (parallel) direction. > > If this was not clear from my reply, I did not objected against RF_CACHEABLE, > but was more to highlight weird needs of seemingly simple architecture, > which are close to RF_CACHEABLE stuff. And, I think that architectures > that care about caching modes, should do provide real pmap_change_attr() > implementation. This might be important e.g. if drm is brought up on > these platforms. heh, on ARM it's not "when". For MIPS it's also now "when". So I guess yeah, we should implement it. -a > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@freebsd.org Fri Feb 26 22:10:52 2016 Return-Path: Delivered-To: freebsd-arch@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 7CA09AB6980 for ; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 69B4D1DBC for ; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 65E57AB697F; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) Delivered-To: arch@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 65745AB697E for ; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5756B1DBA for ; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 47E471A95 for ; Fri, 26 Feb 2016 22:10:52 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id AE3F514150 for ; Fri, 26 Feb 2016 22:10:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id drvqXynmEWO5 for ; Fri, 26 Feb 2016 22:10:48 +0000 (UTC) To: arch@FreeBSD.org DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 2A62F14149 From: Bryan Drewery Subject: Build -j target tags and command output X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <56D0CD68.606@FreeBSD.org> Date: Fri, 26 Feb 2016 14:10:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 22:10:52 -0000 > --- all_subdir_lib/clang/libclangstaticanalyzercheckers --- > --- CastToStructChecker.o --- > --- all_subdir_lib/libmagic --- > --- readcdf.o --- > --- all_subdir_lib/clang --- > /usr/local/bin/ccache c++ -O2 -pipe -fcolor-diagnostics -I/root/git/= freebsd/lib/clang/libclangstaticanalyzercheckers/../../../contrib/llvm/in= clude -I/root/git/freebsd/lib/clang/libclangstaticanalyzercheckers/../../= ../contrib/llvm/tools/clang/include -I/root/git/freebsd/lib/clang/libclan= gstaticanalyzercheckers/../../../contrib/llvm/tools/clang/lib/StaticAnaly= z > er/Checkers -I. -I/root/git/freebsd/lib/clang/libclangstaticanalyzerche= ckers/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM= _ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE= _ARCMT -DCLANG_ENABLE_STATIC_ANALYZER -fno-strict-aliasing -DLLVM_DEFAULT= _TARGET_TRIPLE=3D\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=3D\"x8= 6_64- > unknown-freebsd11.0\" -DDEFAULT_SYSROOT=3D\"\" -MD -MP -MF.depend.CastT= oStructChecker.o -MTCastToStructChecker.o -fstack-protector-strong -Qunus= ed-arguments -std=3Dc++11 -fno-exceptions -fno-rtti -stdlib=3Dlibc++ -Wn= o-c++11-extensions -c /root/git/freebsd/lib/clang/libclangstaticanalyzerc= heckers/../../../contrib/llvm/tools/clang/lib/StaticAnalyzer/Checkers/Cas= tToStru > ctChecker.cpp -o CastToStructChecker.o I'm looking for opinions on whether we should keep or remove the -- lines. Recent changes to make SUBDIR_PARALLEL more wide-spread has made these much more noticeable and spammy. There are cases where they are recursive, if something N levels deep in a SUBDIR_PARALLEL N-make-level build prints something, every parent make prints the target for that subdir. I've tried to mitigate that some but it's a lost cause. bmake purposely prints targets if they have no output so that you know it did try to build the target. That really hurts with bsd.subdir.mk traversals though. There's also a rare case where the --- lines get interspersed or printed on the command line and really mess things up. Removing them would yield potentially hard-to-debug failures since the failed command could be anywhere. At least the 'make stopped' error that follows would print the directory. There is an interesting feature in the meta mode build that will keep a log and print a more detailed error message on failures so you really know which directory failed and what environment it had, but it can be spammy as well since it prints the same error information on the 'another make hit an error, dying' case= s. Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD build output makes sense and removes these --- lines entirely. It would hide the command output but we could optionally show it with a VERBOSE flag, or using meta mode (the very light version which only requires the CMD ran in a .meta file) we could use the meta file to see what command failed. Some examples: NetBSD (prototyped into FreeBSD): > ~/git/freebsd/bin/sh # NO_SUBDIR=3Dyes make MAKEVERBOSE=3D1 > compile sh/mknodes.o > compile sh/mksyntax.o > compile sh/alias.o > compile sh/arith_yacc.o > compile sh/arith_yylex.o > compile sh/cd.o > compile sh/echo.o > compile sh/error.o > compile sh/eval.o > compile sh/exec.o > compile sh/expand.o > compile sh/histedit.o > compile sh/input.o > compile sh/jobs.o > compile sh/kill.o > compile sh/mail.o > compile sh/main.o > compile sh/memalloc.o > compile sh/miscbltin.o > compile sh/mystring.o > compile sh/options.o > compile sh/output.o > compile sh/parser.o > compile sh/printf.o > compile sh/redir.o > compile sh/show.o > compile sh/test.o > compile sh/trap.o > compile sh/var.o > compile sh/builtins.o > compile sh/nodes.o > compile sh/syntax.o > link sh/sh.full > create sh/sh.debug > create sh/sh DIRDEPS_BUILD output: > ~/git/freebsd # WITH_DIRDEPS_BUILD=3Dyes make -C bin/sh -j15 ... > --- /root/git/freebsd/bin/sh.amd64,amd64 1334 --- > @ 1456524548 [2016-02-26 14:09:08] Checking /root/git/freebsd/bin/sh fo= r amd64,amd64 ... > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/.dirdep > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.c > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/token.h > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_incs > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/syntax.c > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/nodes.c > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/alias.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/arith_yacc.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/arith_yylex.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/cd.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/echo.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/error.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/eval.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/exec.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/expand.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/histedit.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/input.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/jobs.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/kill.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mail.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/main.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/memalloc.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/miscbltin.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mystring.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/options.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/output.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/parser.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/printf.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/redir.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/show.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/test.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/trap.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/var.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/nodes.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/syntax.o > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.1.gz > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.full > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh.debug > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/sh > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_files.man1 > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_as.prog > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_libs > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_symlinks.ma= n1 > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_links.man1 > Checking /root/git/freebsd/bin/sh/Makefile.depend: .dirdep.meta builtin= s.c.meta mknodes.o.meta mksyntax.o.meta token.h.meta stage_incs.meta mksy= ntax.meta mknodes.meta > @ 1456524550 [2016-02-26 14:09:10] Finished bin/sh.amd64,amd64 seconds=3D= 2 meta=3D49 created=3D49 --=20 Regards, Bryan Drewery From owner-freebsd-arch@freebsd.org Fri Feb 26 23:20:21 2016 Return-Path: Delivered-To: freebsd-arch@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 307FFAB57FE for ; Fri, 26 Feb 2016 23:20:21 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F2BB11CA4 for ; Fri, 26 Feb 2016 23:20:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id EF245AB57FD; Fri, 26 Feb 2016 23:20:20 +0000 (UTC) Delivered-To: arch@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 EEABEAB57FC for ; Fri, 26 Feb 2016 23:20:20 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0126.outbound.protection.outlook.com [65.55.169.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55A861CA3; Fri, 26 Feb 2016 23:20:19 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from BL2PR05CA0033.namprd05.prod.outlook.com (10.255.226.33) by CY1PR05MB1948.namprd05.prod.outlook.com (10.162.216.18) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 26 Feb 2016 23:20:12 +0000 Received: from BN1BFFO11OLC001.protection.gbl (2a01:111:f400:7c10::1:106) by BL2PR05CA0033.outlook.office365.com (2a01:111:e400:c04::33) with Microsoft SMTP Server (TLS) id 15.1.415.20 via Frontend Transport; Fri, 26 Feb 2016 23:20:12 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; freebsd.org; dkim=none (message not signed) header.d=none;freebsd.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BN1BFFO11OLC001.mail.protection.outlook.com (10.58.145.12) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Fri, 26 Feb 2016 23:20:12 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 26 Feb 2016 15:20:10 -0800 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u1QNK8D62253; Fri, 26 Feb 2016 15:20:08 -0800 (PST) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 489F638551E; Fri, 26 Feb 2016 15:20:08 -0800 (PST) To: Bryan Drewery CC: , Subject: Re: Build -j target tags and command output In-Reply-To: <56D0CD68.606@FreeBSD.org> References: <56D0CD68.606@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Fri, 26 Feb 2016 14:10:48 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <77471.1456528808.1@kaos.jnpr.net> Content-Transfer-Encoding: quoted-printable Date: Fri, 26 Feb 2016 15:20:08 -0800 Message-ID: <77472.1456528808@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11OLC001; 1:E+M/LE8/4+RbOPhe2WFJfPi7h7VPtylHGS+0m84Nb17FqxKNx4V/npuWk3Yo2ytgawA8B758bKG3PekI1VSpz5pc5qEYPWgEmEC2FkWa7JywPerLa7XWDt3YjL5wDQIcGMd2m1yh8DV/f9Ts2S000PvbSAYLJWuiGeKQZY7Lp2To1cQvrjbBBpI2KR+xVQUaJvMkXIYbhKbxLl65a03oxOLSVaxW9z3Cf3gF6S+Es6QzBILQW50uFOWuApfIyiQNpn9mfL5UZxzvd/OQPGq+0oCPY4jnV4fFvfUEaLXfqrOsQ5EWt3VFr1aC3Xl8mJFrQAwgaOiZCEoUD7oOt3/Q58pDfBl1QHrfKO723ngUsjzwJgfEDdTLDcZig6qGqULd5f4YOS8+Q39i4StgQIrbkg== X-Forefront-Antispam-Report: CIP:66.129.239.19; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(377424004)(23726003)(50226001)(92566002)(50466002)(19580395003)(450100001)(97756001)(2810700001)(19580405001)(106466001)(2950100001)(77096005)(1096002)(46406003)(4326007)(76176999)(105596002)(6806005)(11100500001)(2906002)(5001960100002)(107886002)(110136002)(87936001)(50986999)(53416004)(76506005)(5003600100002)(117636001)(47776003)(189998001)(5008740100001)(4001430100002)(86362001)(586003)(1220700001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1948; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1948; 2:whYZLoGbEDmV38ETob+1zQdaYB2xZLKLN6FkeerHT/BJj2WmpanYXg3YhaUpAgI0vF/bFQ51khOtR67c+J7ba5dblpq6hXgeeVL/LUb0DQKdVDJxwI8yIE5fk8FT/dHMvAhdQlvspEfe1d9/nKGqWA==; 3:zR0mQqEpmk/5NggVvS/6lqymMoAMhOF9MzpMIGZ15+4ufxzC+7hn3Kz0ZrRIj1+8STmCC6xmVBjvDDiIXfr2yIxvNzo7UqX2QPMszdeW4ICyZSekMSFON3VUO/bsa5gDoojL4v5YIJgW2GxA539H/WeB/Nr+2llM0F4Q+EUrEV06GVDEqjPD3bByogMHenWz0rMSL7TYGjFQcqrS2R6g2G9QS7BMaozOU+B2x2/dnec=; 25:rheOCvled7y/cE8bHDTCreWM5LbO54qJjdYkNlAPcG0dDWBT0KdHfIZo1XLt6UYt1uWY4WYniChdHZKfqFGRUHwofwKjScnctG25tiJ+a/ZT1dT+t+6RwGj7FwMOhSVdHmM/NbFyUW51eViihhBZN+zbHR726YNlBy0s75G4XXuErhfTq2gABy++8onWaAjsq0gTEB/LuIbLoFsgYpx65MLROFlw0eYGYbaTexR4NBF1bztsl0XgBFLuSgYwPQ7Qhjt4YjSgZrllju+RnxkIsdD0m4NpCxbEN3dS2zxN+xcQ+m6DLj7PfJYW5JTFyndeYK69VyxCGaDMRZmqfgCjwQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB1948; X-MS-Office365-Filtering-Correlation-Id: 7a65b653-71da-44de-319a-08d33f036076 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1948; 20:pL71GoiY7x/OZkl66luKQK5H6vqpglrHLIzX39q3bD6TpEfpKM3fJYdJS8MmIuNYR/6DgtaH0aF9wIDn2LKgVBDy8ereoORLXHv5YeDVpszeITasHsGJFiuJ85uTgVvK01dVw0mZ3j924QR81UbxSXqMnYWCgz9qfdcX2wTUMfXc7D8onwUBgRvFJ4G7ecHsr6F2i1NBhdhUFD3XFS+piYACrrThlv2m+1nk7wcgPUBzGDnkByGXcfZmeL1JCrIB4DtbYFoDl1MyXQTdjfrkP7R7xdWzN+ukg/3zq6Zd3hsKnXn+8aYUxYBFhSqvj9ufrtaWjDGouAmoLyX/U/9UGY/v8Ja+ZxCtM9TAmvIxud4BYK5g1NVK7z2MPp3qPn/u7JGDsSMYbQhUKEnNmtvsBipOSn9EZvov+3+cwdT/KM5WqJJNjQGhFknxdeEl94xYRSUbmwjVazPaLlB77p4gAzSBz2yAUPW7eouwhOELph8Bw94JH8XqU4UMxbCDbYe1 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(13024025)(13023025)(13018025)(5005006)(13015025)(13017025)(10201501046)(3002001); SRVR:CY1PR05MB1948; BCL:0; PCL:0; RULEID:; SRVR:CY1PR05MB1948; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1948; 4:wyK6DBz3ku/hclYr4tO0Gjk8g8/+NvlJk0+uoc6F9UGkF7pxXcw33rTvtUoLJqtfPvGWq82p16nQYXDpuRtEhe5zEM3dcEoKQB2KToafVnQ70nBi6sXi90oebsBF6g8gXdKrZ++xNLpywqn7G3bQBZj24gMNyZ1MzfwN8IU1K/TMEPMon/GMsZQRq2Q2vRosri9HAUo5Oy5Av9AakUpVefffBNZWTDHBintEzkKQj/gJFwT4x/YkqkaGK5Sh5bt+PmTVeH5zNrUPhUw098FVTOO6orUvfG+upKNza+SgRyrL7pepbP/QnOO76RNXbk1MpqeXK6BRJpnYDqhQgCWGvsxFoWk+SJqE+3Z1LTVFoGzPgVdi9CLb69OiwweVy6L18qO6VNWhhWi0Xvosu2XIm4lQdKUo0nllKpheze9PeMTmzlspzS1Lcir9KciLecXXOIAj12djNOB9cEwJa73A5w== X-Forefront-PRVS: 0864A36BBF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1948; 23:WeL+rgaESu9yyQdcY3dZ9zzrm32mWFqIJ6L8GZKK6?= =?us-ascii?Q?6UQ5cc2vxpyHOVWyjv6OdNEAw+dQyb/NYbBHSRLXk9tuSe8/P6HCB2HFx+18?= =?us-ascii?Q?BakpNCCBEAXeojTTYzn+i/IDqnDAONw6ZJWJ/GKmsZM89M/HIdPmB9tsmVRk?= =?us-ascii?Q?fvhtitN9iQ1zX6lkJnkUNv8RmI5tm8WvTig19pBIzgegTo5BM+PkGVESSYgS?= =?us-ascii?Q?Nxc0G/WUSCEiLbM9KJ5HJFoo6ffV/uiG2cQ5xUoqgxlWxEw/Rjt14LTkHLK1?= =?us-ascii?Q?+cdtweQ8O2VikgqPve2XJesmrVbVZEH5VaCUMORwFktxH67fsBR6ix/6DVJq?= =?us-ascii?Q?OWZ/W98B0nVeM+Lgq2GHXvEOkLu9ShD9OQsgu7IHG47W/5Pg6v2jE/SLoUsX?= =?us-ascii?Q?MW1ENb0LA1jsigb9XR2zOtFi7LmA7hAlJGDVlXM3XE6h4WvM2v8YfxwaPxMP?= =?us-ascii?Q?MiI7/3GJrjIfwE93mCg7cY+L4aDl5RGpDMB57qYfQpbJkTmxLkuHz9DwPnSj?= =?us-ascii?Q?G5QSD6QBG9rrfHnHhOF3UaNVM6vlqhpAhi8V3vMs2QacI/hvs8JF6sGfNbbN?= =?us-ascii?Q?nZv6VnRZsF3mRFKJa0PJgjmp96z4TtP5nTrA3gIj6ybNts/SbNyXEfqFmZ8C?= =?us-ascii?Q?vk1lYxmJrxUf2t2P3tFC8KsItx8YhBEBKkFtWb1f1lFpBEqfnwUkDWP23Of6?= =?us-ascii?Q?tbDRE844OxEluBUGV/FcVZlDCWVHjRzARGWo+jFJGjrnaKb5OXHaef/4N1Vk?= =?us-ascii?Q?cDgf+N7207Me/bIAwAKCXy7Y+W+e9J98XcaI4nma8HLxgMJ0nOofWyImR7dS?= =?us-ascii?Q?G2VnVY4/wtjAVnS+VJ64TTmZCDrO1Og3vZnYeqeX7TLtVsjMba0Qbfo1wosm?= =?us-ascii?Q?HToDytV+q1kyjOnAPv6kASFi0qlBoFN9nyxLZDV0SOG3apxboUOAQTQGmfSJ?= =?us-ascii?Q?vKS8pOA6/4NGzfFvz0czogak9qMx5jtHtDgKiZ4aZekQ74nJ4VXLU9rDJuh0?= =?us-ascii?Q?ZqxXzRtDbsqVtFguFdNVgj91ZZ+ihNG+6cwpwmjNDl8ZNOhysxfGuNXmLoAG?= =?us-ascii?Q?G88Up5TJYq0abuv9jf2iLZxVSuscWrvkpU7vWuzl/5Xe6ruG6/mJLUb48Jcv?= =?us-ascii?Q?tVErnr0F9ibPJeOrSlPmuavnJFbAmKY?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1948; 5:A+VX42BA1pQyN7PAVAhxzmVsvLopQajg/0isjKbOubZf9nCpxsfzX4k+c7Jk2BuM1fjynQGLUgknVqhDEZ8GaATQYdl2HLLwbZi0Ey+b8YZWJsgQpDJM6/86M2C6eVVttTvLZb0ZnuoaxrxrgXZXNw==; 24:1knQSQLNR5jpcAMm1S1RNi2aHyGTmJxlKLC6OmhSc808KmIQzEDi2vUlsaZTCOIzYxMDEhCw+evCA4zQHpTwT61mhPIqA96i71gyG+GylvI= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2016 23:20:12.1438 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1948 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:20:21 -0000 Bryan Drewery wrote: > I'm looking for opinions on whether we should keep or remove the -- Keep. Without them it is virtually impossible to identify which job produced certain output. Even with them, the log from a parallel hirerarchical build can get confusing - especially when multiple makes are writing at the same time. But you are still better off with some clues. > Removing them would yield potentially hard-to-debug failures since the Yes, pls don't do that. > failed command could be anywhere. At least the 'make stopped' error > that follows would print the directory. There is an interesting feature Yes, but generally the exciting stuff that caused the stoppage is earlier in the log. The --- lines allow use of scripts to demux the output. > in the meta mode build that will keep a log and print a more detailed > error message on failures so you really know which directory failed and > what environment it had, but it can be spammy as well since it prints > the same error information on the 'another make hit an error, dying' cas= es. Yes, the issue is largely moot with dirdeps/meta mode build. As your example clearly demonstrates. Not all targets produce a .meta file, and for these you may still get --- job lines, but they can hardly be considered an issue. All the gory details - that you need to debug issues saved in in the .meta file with no contamination from other jobs > Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD > build output makes sense and removes these --- lines entirely. It would With dirdeps build the noise that NetBSD outputs is just noise: Checking /tank/home/sjg/work/NetBSD/current/src/lib/csu for i386 ... Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/gcrt0.o Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/sysident_assy= m.h Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/crtn.o --- gcrt0.o --- # compile csu/gcrt0.o --- sysident_assym.h --- # create csu/sysident_assym.h --- crtn.o --- # compile csu/crtn.o > DIRDEPS_BUILD output: > = > > ~/git/freebsd # WITH_DIRDEPS_BUILD=3Dyes make -C bin/sh -j15 > ... > > --- /root/git/freebsd/bin/sh.amd64,amd64 1334 --- > > @ 1456524548 [2016-02-26 14:09:08] Checking /root/git/freebsd/bin/sh f= or amd64,amd64 ... > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/.dirdep > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.c > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes.o > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax.o > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/token.h > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_incs > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_symlinks.m= an1 > > Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_links.man1 > > Checking /root/git/freebsd/bin/sh/Makefile.depend: .dirdep.meta builti= ns.c.meta mknodes.o.meta mksyntax.o.meta token.h.meta stage_incs.meta mksy= ntax.meta mknodes.meta > > @ 1456524550 [2016-02-26 14:09:10] Finished bin/sh.amd64,amd64 seconds= =3D2 meta=3D49 created=3D49 From owner-freebsd-arch@freebsd.org Fri Feb 26 23:30:37 2016 Return-Path: Delivered-To: freebsd-arch@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 B1754AB5D9E for ; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 9DF2F5FB for ; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9CA88AB5D9D; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) Delivered-To: arch@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 9C412AB5D9C for ; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8DB225FA; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id 7E2D610C2; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 38455143AB; Fri, 26 Feb 2016 23:30:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id BVngh4SXjGib; Fri, 26 Feb 2016 23:30:29 +0000 (UTC) Subject: Re: Build -j target tags and command output DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 40B5C143A5 To: "Simon J. Gerraty" References: <56D0CD68.606@FreeBSD.org> <77472.1456528808@kaos.jnpr.net> Cc: arch@freebsd.org From: Bryan Drewery X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <56D0E017.4070305@FreeBSD.org> Date: Fri, 26 Feb 2016 15:30:31 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <77472.1456528808@kaos.jnpr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:30:37 -0000 On 2/26/16 3:20 PM, Simon J. Gerraty wrote: > Bryan Drewery wrote: >> I'm looking for opinions on whether we should keep or remove the -- >=20 > Keep. >=20 > Without them it is virtually impossible to identify which job produced > certain output. >=20 > Even with them, the log from a parallel hirerarchical build can get > confusing - especially when multiple makes are writing at the same time= . > But you are still better off with some clues. >=20 >> Removing them would yield potentially hard-to-debug failures since the >=20 > Yes, pls don't do that. >=20 >> failed command could be anywhere. At least the 'make stopped' error >> that follows would print the directory. There is an interesting featu= re >=20 > Yes, but generally the exciting stuff that caused the stoppage is > earlier in the log. > The --- lines allow use of scripts to demux the output. >=20 >> in the meta mode build that will keep a log and print a more detailed >> error message on failures so you really know which directory failed an= d >> what environment it had, but it can be spammy as well since it prints >> the same error information on the 'another make hit an error, dying' c= ases. >=20 > Yes, the issue is largely moot with dirdeps/meta mode build. > As your example clearly demonstrates. Yes, though I would still suggest disabling .MAKE.MODE.PREFIX in that mode since it is not needed when a meta file is created due to the full path to object. Though we would need to resolve the non-meta targets not printing the 'Building' line somehow. Perhaps a way to make .MAKE.JOB.PREFIX fully changeable (not forcing the --- on the end) and supporting ${.TARGET} like .MAKE.META.PREFIX and then only showing it when not creating a meta file when in meta mode. But *still* show the command output since there is no .meta file to track the command for debugging. The point is we could get Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/clean rm -f *.o vs --- all_subdir --- --- all_subdir_bin --- --- all_subdir_bin/sh_clean --- --- clean --- rm -f *.o Of course the recursive printing by sub-makes would have to be disabled somehow in this mode. Backing up to simpler changes now though... I thought I asked you this before but I couldn't find the mail. Just having a '.JOBSILENT' on a target would be nice to hide subdir printing but not hide the command output (requiring .SILENT on clean: obj:, etc), and then also allowing ${.TARGET} to work in .MAKE.JOB.PREFIX so that we can get something like the following, where the job is only the final one and not any of the subdir ones. --- /usr/obj/root/git/freebsd/amd64.amd64/bin/sh (clean) --- rm -f *.o >=20 > Not all targets produce a .meta file, and for these you may still get > --- job lines, but they can hardly be considered an issue. >=20 > All the gory details - that you need to debug issues saved in > in the .meta file with no contamination from other jobs >=20 >> Longterm, I think a merge between DIRDEPS_BUILD output and the NetBSD >> build output makes sense and removes these --- lines entirely. It wou= ld >=20 > With dirdeps build the noise that NetBSD outputs is just noise: >=20 > Checking /tank/home/sjg/work/NetBSD/current/src/lib/csu for i386 ... > Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/gcrt0.o > Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/sysident_a= ssym.h > Building /tank/home/sjg/work/NetBSD/current/obj/i386/lib/csu/crtn.o > --- gcrt0.o --- > # compile csu/gcrt0.o > --- sysident_assym.h --- > # create csu/sysident_assym.h > --- crtn.o --- > # compile csu/crtn.o >=20 Well I didn't mean literally a merge, I meant more picking from both. Granted, the NetBSD method is very hard to implement fully and won't work for custom build targets and downstream build changes since it requires adding an echo into every target. >=20 >> DIRDEPS_BUILD output: >> >>> ~/git/freebsd # WITH_DIRDEPS_BUILD=3Dyes make -C bin/sh -j15 >> ... >>> --- /root/git/freebsd/bin/sh.amd64,amd64 1334 --- >>> @ 1456524548 [2016-02-26 14:09:08] Checking /root/git/freebsd/bin/sh = for amd64,amd64 ... >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/.dirdep >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/builtins.c >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mknodes.o >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/mksyntax.o >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/token.h >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_incs >=20 >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_symlinks.= man1 >>> Building /usr/obj/root/git/freebsd/amd64.amd64/bin/sh/stage_links.man= 1 >>> Checking /root/git/freebsd/bin/sh/Makefile.depend: .dirdep.meta built= ins.c.meta mknodes.o.meta mksyntax.o.meta token.h.meta stage_incs.meta mk= syntax.meta mknodes.meta >>> @ 1456524550 [2016-02-26 14:09:10] Finished bin/sh.amd64,amd64 second= s=3D2 meta=3D49 created=3D49 --=20 Regards, Bryan Drewery From owner-freebsd-arch@freebsd.org Fri Feb 26 23:47:15 2016 Return-Path: Delivered-To: freebsd-arch@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 984C9AB632B for ; Fri, 26 Feb 2016 23:47:15 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 668CCD0E for ; Fri, 26 Feb 2016 23:47:15 +0000 (UTC) (envelope-from sjg@juniper.net) Received: by mailman.ysv.freebsd.org (Postfix) id 63548AB632A; Fri, 26 Feb 2016 23:47:15 +0000 (UTC) Delivered-To: arch@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 4911EAB6329 for ; Fri, 26 Feb 2016 23:47:15 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8D78D0D; Fri, 26 Feb 2016 23:47:14 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from SN1PR05CA0022.namprd05.prod.outlook.com (10.163.68.160) by BY1PR0501MB1608.namprd05.prod.outlook.com (10.160.203.16) with Microsoft SMTP Server (TLS) id 15.1.415.20; Fri, 26 Feb 2016 23:47:08 +0000 Received: from BY2FFO11FD056.protection.gbl (2a01:111:f400:7c0c::187) by SN1PR05CA0022.outlook.office365.com (2a01:111:e400:5197::32) with Microsoft SMTP Server (TLS) id 15.1.415.20 via Frontend Transport; Fri, 26 Feb 2016 23:47:07 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from p-emfe01b-sac.jnpr.net (66.129.239.19) by BY2FFO11FD056.mail.protection.outlook.com (10.1.15.193) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Fri, 26 Feb 2016 23:47:07 +0000 Received: from magenta.juniper.net (172.17.27.123) by p-emfe01b-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 26 Feb 2016 15:47:06 -0800 Received: from kaos.jnpr.net (kaos.jnpr.net [172.21.16.84]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u1QNl6D91838; Fri, 26 Feb 2016 15:47:06 -0800 (PST) (envelope-from sjg@juniper.net) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 44F8D38551E; Fri, 26 Feb 2016 15:47:06 -0800 (PST) To: Bryan Drewery CC: , Subject: Re: Build -j target tags and command output In-Reply-To: <56D0E017.4070305@FreeBSD.org> References: <56D0CD68.606@FreeBSD.org> <77472.1456528808@kaos.jnpr.net> <56D0E017.4070305@FreeBSD.org> Comments: In-reply-to: Bryan Drewery message dated "Fri, 26 Feb 2016 15:30:31 -0800." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <78235.1456530426.1@kaos.jnpr.net> Date: Fri, 26 Feb 2016 15:47:06 -0800 Message-ID: <78236.1456530426@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CPI:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(189002)(24454002)(199003)(189998001)(47776003)(2950100001)(76506005)(53416004)(50466002)(92566002)(46406003)(450100001)(107886002)(50986999)(5003600100002)(19580395003)(11100500001)(19580405001)(4001430100002)(6806005)(5008740100001)(110136002)(87936001)(5001960100002)(76176999)(4326007)(106466001)(105596002)(97756001)(586003)(2810700001)(50226001)(23726003)(1096002)(1220700001)(2906002)(77096005)(86362001)(117636001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1608; H:p-emfe01b-sac.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD056; 1:jKFQTEndW7oB50RLYeAm97A3u2NRqgyXQsNdu+Zrxx7wQiDdPU/wJZO9j8Cjea2GwugMOnRNtm2SUhFcOBJKgpTJ83hWKX/DNMNwgNpEYiSlr6FXoe4htwSYp6hFcUDOQHlWF337rGNPKqxfGgINaZniGlnJeFpuRr1/wn2/t4AwTcFhi4IuEc6Fr9eb1pQikf4nnXJ2tuamcvf8xh0BGm0CxN1pbaq1Df1hdTffRZYCQ0tlHDI1UQc09ZxB64LC1qnLEO3OHkAE9ZKqsxqA8mZVbLcbbBpkzaRF8uVGOC5Di5EUY0vdYkXzCQyJKzqXwbxDTddlm2mUrE3hgUSXUN+Z5U5EmWftmkrs3FM1gas5gL7AZDcL4JgEuzEIIny1tqsi6vgjH6cjfFsVg2kwTmHlypsm+yZZqelB24in13s= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1608; 2:O8lhY5608N8PWY9tGoTm6kbBfzZYlOddCwU5VSCttBhceZA+G8e24OhVGo0mttdGcC84SR34VFiYnwbEZ7M6Etu7gs4o1AIoJVmUOr5wVbzm7yOv/D7ZWczydbMo1on4DnMJnprWODPz8lkyQgXqQw==; 3:k0P1kbY7na8y5wO0B+rhdp63H1ZSLGWHHqX69irlp6C0ygPTjxnJh64utjcyGlwbaPbEpfl9AbF91e/sLxQSmX7+uWFCGdl9MZ+pvPZXKcoA6AECDkyTdE1IIGVWffGg/D1vnkfPRq9CQTFr9QEv/QPtxvcoIUneSknJdqesgV0=; 25:Q1PjGP6y8AFUtU7H8eaY94due4e4BhIHPMqzsSuROq5vnTqqtveDz+7xhhV36QNVI8Yf0AbKWsnkpbxXebJOfpVAZbTQjINb4EEP7c4fhp91Yi0KZRzxe95SwPKQ/8a6AF8Jah9gbaq5P4a4ayjb0oBaixlA21Zyfy0Ln8nHCQzAj5gtVxLuUPslmDdCWzX2e47LUw99BSMsIKWsJNAT2lduOj4HXiPo9ywqh5lqaKrK3AWoqLBfB+8dM/KZbt5ad28Jt1OzBANybmPF9+7zK5G3BHXgSAJh23g/hqjalYA7hLgXS29PZ6te76CLEy+QPK1Ta5VTtnBoB1cxYSnUGQ== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1608; X-MS-Office365-Filtering-Correlation-Id: 95afb795-ee90-4576-2688-08d33f07231f X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1608; 20:z4Cgq+d6wCaeR7iZr0fYFcdXEBw9/qiOMrZ065PYtjIAFWRaEqYwOVVULV4IT7f+HTpDhbgVghmJGA+fVuBi/UC4aLiBDgx1GrG8Ybv7BpKeWdSNhKRMN2lBd/c2Qh2yEB7fOWEjIrzFZHkLtbpC4Nn6r0qghDHPEIKvng0ojiB0R9XKoUxtQ0fEMMnPTmu5l4Z25a3nm6u1XLMM47UxaF1k0VaZ4YsaUD09l2rwTa3hKrdMmiF3vIEn4qmWl8NAovIohpx+a2/dcjB0hjjMDA9UPqtM5h/5jXkdJz5cTS0eKuGi5ysfqMLpfJZmPOxycCX6hwDvSoDSo426XEOoAy/07iSVlBYE2gvMUHhNL5KYQpg6hLX0f8s433m2L0FHOVU/jZF7OQywZfveSSmkEw1GHV2+MhqhNzP9mSzb9XApn/94jrk6sArrE3Acey6GlHrw9xOPcsARbnnwAtt0NgZKwpRdXUTm+SE911X3boSc5r+r//wD8yAwEinvPBvb X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13018025)(13023025)(13015025)(13017025)(13024025)(5005006)(8121501046)(10201501046)(3002001); SRVR:BY1PR0501MB1608; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1608; X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1608; 4:5BPv44INcmtRjHdD3rKoeMm3K4P0WncFZzAHBBGlhRmxM4OxXdJme4TEaKeK3YMfz8kOejs5gJxnd5SwBrTp/J7xBv3Fs5nZSnXk9vNxFb5fNBGuqfTbOGzlln1UcReLM7EZVgCno0sShGcTgxH+mmU2KDYh4cJGZK8HolcuwEZg3HNqo0gkE+yqlgptAbsaOr8iLyIE5vu4Lp/ch8ccQ+i1l8emWOvNppgNswt0j3+y+LOzaMGN6EA2hf7LDDEsIMkWnBiHdGdyyp1tT1riJAlN4D3IrMQc+a+5yOtAQ1QiG0zj192dZZryu6gkn889zOzLsZZKXUHylTVnKXSh86+wypKzheejIoLoM+u9xjfc6qWZRW6BGlcu9FgrPdaMszt7Fz2s5Ypf2mGJq3AopEYlLa6eGd67JXLIa7xPOqOiaJF0Yt4ULkbFRRwrUJ2S29J0Ure1ELB8Z0vjAhnewQ== X-Forefront-PRVS: 0864A36BBF X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BY1PR0501MB1608; 23:uAtqi7GwiWN1+jWF7c81tu2C5o/WvMyWjSiij7e?= =?us-ascii?Q?lwYOSGyDLSh+SnJiY3vsL1Vtzi5qrzmiSFHpLoMjLn8n0/4ApHlrFKeL3P8G?= =?us-ascii?Q?sOEWsMYrbH6bjc/8IxPB3ma6xZGoTFKUKILaebQtAzAaC1tN8RWJjmQhZAo0?= =?us-ascii?Q?gquBVGLCGYZlKNc3dq8eDfsSDuFlClYB6tfyCAWeASDitAcKBHtW0t2U+QSX?= =?us-ascii?Q?CD3p1E6C+7mkAYqQU4CPFOUjEbN7hoLg03/7LiV6ETPFvWdCYQfDGsLs8Bii?= =?us-ascii?Q?/rQtqOuAFBPzHbQTxZfhZAgbxYPzwL0IsV9TjlVJvDOf29QEKJxc5YXuh67W?= =?us-ascii?Q?w7vr/sOaeXGaB1jhzqIXAaapLaYJZ8cuyGXML7xOFeZb4kiecxAkPapGiakm?= =?us-ascii?Q?oEwv2qSz3PPmAo+Kntt16qD8rNWXAuN6W43b8eyoe2WkIrYUMrRwmSugSshT?= =?us-ascii?Q?2JxyjTeJkJQmBr2tWHY/VQbT9qOzzUAQIOKDNctri9po0yCa64TG5760j7eW?= =?us-ascii?Q?KvSsU3SAF0A+HZgluFXkhAGOtV+/gCx8QeUhNsHIFjHSdvQ6mDzBOkPStdEk?= =?us-ascii?Q?6U2x4LTwguz8UTIINz1+FU9156SwsWtxlRW1NYdQ9Em3vVPdaWMbXDexB4uK?= =?us-ascii?Q?Oa08Fmm5XxDTI1f6p0/UGM9FnSrDNaMKTPVBARf4EmL3/fd9i4+YhXaN6Mg4?= =?us-ascii?Q?DFXNdkDVSefcoH0qEs7zZRY9ZY9tLxcigDdcSwvPdWOEXfgk80cfOpcyX+z1?= =?us-ascii?Q?NOuGjRStTKh7UR+w8IrfpnWkls6jXRF0cr1sMTw6agoqTae89OJBNlLrDgDR?= =?us-ascii?Q?prbZG/aAvj0gk8bbMLy4+SmU9f1WBCKz7Ov2lmSP9DVNmN19Bqyif3ymRSZV?= =?us-ascii?Q?GY/TFCZboPst3vg/GSCsjw0tUZt6BreG4wcXP97pNTof7p1mE7VTO804R9BD?= =?us-ascii?Q?UjvIzAoaCjz4fZApHGhKmMKNW2RFhMkC7F43UzwPfZdTIj4qpIdOo6/aT9SX?= =?us-ascii?Q?rHSeu4dH1lbMca4iM4H23+Fpkho5kUu/92LXDDrF9DbuE7f0011T8VpLNBuG?= =?us-ascii?Q?GJlmT4W4hY4Go/a1wtbKmoRGrl5fwhGnFmskkjXUkkawuUnQmYDrt4mXZcSZ?= =?us-ascii?Q?/f54j8Ke4B5Y=3D?= X-Microsoft-Exchange-Diagnostics: 1; BY1PR0501MB1608; 5:lfE6szv8qDHbo9Q0hBIcHNQHeatcewqldgDCbnvxfzcUnWDbhDbrucxbEx/giKc0Cja6/GiiFBuIZRabTYKSm2/OMJL/kk9inbyvd9lHLLAr0Z33CCEDJvFU2Gsr6hS+fcmINbzFiO7NT73xbwekCw==; 24:2fnIP5UJYEGEl26mtyNA0aOo+8FKVMt1PPafFmIZtncUM0vCxWlmTvttYrcU5FWZtvjNEOGyC4GEcYH+e+op6cDnzNkBXbSlcQecE1n+bfs= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2016 23:47:07.3752 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[p-emfe01b-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1608 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:47:15 -0000 Bryan Drewery wrote: > Yes, though I would still suggest disabling .MAKE.MODE.PREFIX in that > mode since it is not needed when a meta file is created due to the full > path to object. Though we would need to resolve the non-meta targets > not printing the 'Building' line somehow. > > Perhaps a way to make .MAKE.JOB.PREFIX fully changeable (not forcing the > --- on the end) and supporting ${.TARGET} like .MAKE.META.PREFIX and > then only showing it when not creating a meta file when in meta mode. That already happens when .MAKE.MODE includes "meta" and "silent=yes" Frankly I would prefer to *not* make the non-meta targets look exactly like meta targets in the log - since then people will waste time looking for and filing bug reports about missing .meta files. The difference does not need to be significant - just distinguishable. > I thought I asked you this before but I couldn't find the mail. Just > having a '.JOBSILENT' on a target would be nice to hide subdir printing > but not hide the command output (requiring .SILENT on clean: obj:, etc), > and then also allowing ${.TARGET} to work in .MAKE.JOB.PREFIX so that we > can get something like the following, where the job is only the final > one and not any of the subdir ones. > > --- /usr/obj/root/git/freebsd/amd64.amd64/bin/sh (clean) --- > rm -f *.o My solution to that is to eliminate the recursion ;-) But I'll give the above some thought. From owner-freebsd-arch@freebsd.org Sat Feb 27 02:13:43 2016 Return-Path: Delivered-To: freebsd-arch@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 7364EAB5BA1 for ; Sat, 27 Feb 2016 02:13:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C80114B4 for ; Sat, 27 Feb 2016 02:13:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id F2555B97D for ; Fri, 26 Feb 2016 21:13:41 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Wrapper API for static bus_dma allocations Date: Fri, 26 Feb 2016 17:10:53 -0800 Message-ID: <2856669.mkVhDvxH7k@ralph.baldwin.cx> User-Agent: KMail/4.14.3 (FreeBSD/10.2-STABLE; KDE/4.14.3; amd64; ; ) In-Reply-To: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 26 Feb 2016 21:13:42 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 02:13:43 -0000 On Thursday, January 29, 2015 03:37:19 PM John Baldwin wrote: > The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for > descriptor rings) can be a bit obtuse to use in that it require a bit of > boilerplate to create a tag, allocate memory for the tag, then load it to get > the bus address. Similarly, freeing it also requires several steps. In > addition, some of the steps are a bit subtle (e.g. the need to check for an > error in the bus_dma callback instead of from bus_dmamap_load()) and not all > drivers get those correct. > > To try to make this simpler I've written a little wrapper API that tries to > provide a single call to allocate a buffer and a single call to free a buffer. > Each buffer is described by a structure defined by the API, and if the call to > allocate a buffer succeeds, the structure contains both a pointer to the > buffer in the kernel's address space as well as a bus address of the buffer. > > In the interests of simplicity, this API does not allow the buffer to be quite > as fully configured as the underlying bus_dma API, instead it aims to handle > the most common cases that are used in most drivers. As such, it assumes that > the buffer must be one contiguous range of DMA address space, and the only > parameters that can be specified are the parent tag, the alignment of the > buffer, the lowaddr parameter, the size of the buffer to allocate, and the > flags parameter that is normally passed to bus_dmamem_alloc(). I believe that > this should be sufficient to cover the vast majority of the drivers in our > tree. > > I've included below a patch that contains the wrapper API along with a sample > conversion of the ndis driver (chosen at random). If folks like this idea I > will update the patch to include manpage changes as well. > > --- //depot/vendor/freebsd/src/sys/compat/ndis/subr_ndis.c > +++ //depot/user/jhb/cleanup/sys/compat/ndis/subr_ndis.c > @@ -186,7 +186,6 @@ > static ndis_status NdisMAllocateMapRegisters(ndis_handle, > uint32_t, uint8_t, uint32_t, uint32_t); > static void NdisMFreeMapRegisters(ndis_handle); > -static void ndis_mapshared_cb(void *, bus_dma_segment_t *, int, int); > static void NdisMAllocateSharedMemory(ndis_handle, uint32_t, > uint8_t, void **, ndis_physaddr *); > static void ndis_asyncmem_complete(device_object *, void *); > @@ -1387,23 +1386,6 @@ > bus_dma_tag_destroy(sc->ndis_mtag); > } > > -static void > -ndis_mapshared_cb(arg, segs, nseg, error) > - void *arg; > - bus_dma_segment_t *segs; > - int nseg; > - int error; > -{ > - ndis_physaddr *p; > - > - if (error || nseg > 1) > - return; > - > - p = arg; > - > - p->np_quad = segs[0].ds_addr; > -} > - > /* > * This maps to bus_dmamem_alloc(). > */ > @@ -1443,35 +1425,17 @@ > * than 1GB of physical memory. > */ > > - error = bus_dma_tag_create(sc->ndis_parent_tag, 64, > - 0, NDIS_BUS_SPACE_SHARED_MAXADDR, BUS_SPACE_MAXADDR, NULL, > - NULL, len, 1, len, BUS_DMA_ALLOCNOW, NULL, NULL, > - &sh->ndis_stag); > + error = bus_dma_mem_create(&sh->ndis_mem, sc->ndis_parent_tag, 64, > + NDIS_BUS_SPACE_SHARED_MAXADDR, len, BUS_DMA_NOWAIT | BUS_DMA_ZERO); > > if (error) { > free(sh, M_DEVBUF); > return; > } > > - error = bus_dmamem_alloc(sh->ndis_stag, vaddr, > - BUS_DMA_NOWAIT | BUS_DMA_ZERO, &sh->ndis_smap); > - > - if (error) { > - bus_dma_tag_destroy(sh->ndis_stag); > - free(sh, M_DEVBUF); > - return; > - } > + *vaddr = sh->ndis_mem.dma_vaddr; > + paddr->np_quad = sh->ndis_mem.dma_baddr; > > - error = bus_dmamap_load(sh->ndis_stag, sh->ndis_smap, *vaddr, > - len, ndis_mapshared_cb, (void *)paddr, BUS_DMA_NOWAIT); > - > - if (error) { > - bus_dmamem_free(sh->ndis_stag, *vaddr, sh->ndis_smap); > - bus_dma_tag_destroy(sh->ndis_stag); > - free(sh, M_DEVBUF); > - return; > - } > - > /* > * Save the physical address along with the source address. > * The AirGo MIMO driver will call NdisMFreeSharedMemory() > @@ -1482,8 +1446,6 @@ > */ > > NDIS_LOCK(sc); > - sh->ndis_paddr.np_quad = paddr->np_quad; > - sh->ndis_saddr = *vaddr; > InsertHeadList((&sc->ndis_shlist), (&sh->ndis_list)); > NDIS_UNLOCK(sc); > } > @@ -1581,13 +1543,13 @@ > l = sc->ndis_shlist.nle_flink; > while (l != &sc->ndis_shlist) { > sh = CONTAINING_RECORD(l, struct ndis_shmem, ndis_list); > - if (sh->ndis_saddr == vaddr) > + if (sh->ndis_mem.dma_vaddr == vaddr) > break; > /* > * Check the physaddr too, just in case the driver lied > * about the virtual address. > */ > - if (sh->ndis_paddr.np_quad == paddr.np_quad) > + if (sh->ndis_mem.dma_baddr == paddr.np_quad) > break; > l = l->nle_flink; > } > @@ -1604,9 +1566,7 @@ > > NDIS_UNLOCK(sc); > > - bus_dmamap_unload(sh->ndis_stag, sh->ndis_smap); > - bus_dmamem_free(sh->ndis_stag, sh->ndis_saddr, sh->ndis_smap); > - bus_dma_tag_destroy(sh->ndis_stag); > + bus_dma_mem_free(&sh->ndis_mem); > > free(sh, M_DEVBUF); > } > --- //depot/vendor/freebsd/src/sys/dev/if_ndis/if_ndisvar.h > +++ //depot/user/jhb/cleanup/sys/dev/if_ndis/if_ndisvar.h > @@ -66,10 +66,7 @@ > > struct ndis_shmem { > list_entry ndis_list; > - bus_dma_tag_t ndis_stag; > - bus_dmamap_t ndis_smap; > - void *ndis_saddr; > - ndis_physaddr ndis_paddr; > + struct bus_dmamem ndis_mem; > }; > > struct ndis_cfglist { > --- //depot/vendor/freebsd/src/sys/kern/subr_bus_dma.c > +++ //depot/user/jhb/cleanup/sys/kern/subr_bus_dma.c > @@ -540,3 +540,66 @@ > > return (0); > } > + > +struct bus_dma_mem_cb_data { > + struct bus_dmamem *mem; > + int error; > +}; > + > +static void > +bus_dma_mem_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) > +{ > + struct bus_dma_mem_cb_data *d; > + > + d = arg; > + d->error = error; > + if (error) > + return; > + d->mem->dma_baddr = segs[0].ds_addr; > +} > + > +int > +bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > + bus_size_t alignment, bus_addr_t lowaddr, bus_size_t len, int flags) > +{ > + struct bus_dma_mem_cb_data d; > + int error; > + > + bzero(mem, sizeof(*mem)); > + error = bus_dma_tag_create(parent, alignment, 0, lowaddr, > + BUS_SPACE_MAXADDR, NULL, NULL, len, 1, len, 0, NULL, NULL, > + &mem->dma_tag); > + if (error) { > + bus_dma_mem_free(mem); > + return (error); > + } > + error = bus_dmamem_alloc(mem->dma_tag, &mem->dma_vaddr, flags, > + &mem->dma_map); > + if (error) { > + bus_dma_mem_free(mem); > + return (error); > + } > + d.mem = mem; > + error = bus_dmamap_load(mem->dma_tag, mem->dma_map, mem->dma_vaddr, len, > + bus_dma_mem_cb, &d, BUS_DMA_NOWAIT); > + if (error == 0) > + error = d.error; > + if (error) { > + bus_dma_mem_free(mem); > + return (error); > + } > + return (0); > +} > + > +void > +bus_dma_mem_free(struct bus_dmamem *mem) > +{ > + > + if (mem->dma_baddr != 0) > + bus_dmamap_unload(mem->dma_tag, mem->dma_map); > + if (mem->dma_vaddr != NULL) > + bus_dmamem_free(mem->dma_tag, mem->dma_vaddr, mem->dma_map); > + if (mem->dma_tag != NULL) > + bus_dma_tag_destroy(mem->dma_tag); > + bzero(mem, sizeof(*mem)); > +} > --- //depot/vendor/freebsd/src/sys/sys/bus_dma.h > +++ //depot/user/jhb/cleanup/sys/sys/bus_dma.h > @@ -337,4 +337,29 @@ > > #endif /* __sparc64__ */ > > +/* > + * A wrapper API to simplify management of static mappings. > + */ > + > +struct bus_dmamem { > + bus_dma_tag_t dma_tag; > + bus_dmamap_t dma_map; > + void *dma_vaddr; > + bus_addr_t dma_baddr; > +}; > + > +/* > + * Allocate a mapping. On success, zero is returned and the 'dma_vaddr' > + * and 'dma_baddr' fields are populated with the virtual and bus addresses, > + * respectively, of the mapping. > + */ > +int bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > + bus_size_t alignment, bus_addr_t lowaddr, > + bus_size_t len, int flags); > + > +/* > + * Release a mapping created by bus_dma_mem_create(). > + */ > +void bus_dma_mem_free(struct bus_dmamem *mem); > + > #endif /* _BUS_DMA_H_ */ Ping. The last time I brought this up we ended up off in the weeds a bit about changes to the bus dma API in general. However, I think that even if we reduce the number of args to bus_dma_create_tag you are still left with managing a tag per static allocation etc. I'm working on porting a driver today where I basically just copied this into the driver directly rather than having to implement it all by hand for the umpteenth time. Are folks seriously opposed to having a single function you can call to allocate a static DMA mapping? -- John Baldwin From owner-freebsd-arch@freebsd.org Sat Feb 27 05:39:29 2016 Return-Path: Delivered-To: freebsd-arch@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 9C01AAB570F for ; Sat, 27 Feb 2016 05:39:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6136DF63 for ; Sat, 27 Feb 2016 05:39:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x236.google.com with SMTP id d32so25495877qgd.0 for ; Fri, 26 Feb 2016 21:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=bgDBvfDtcl0nSd0QdhX4BoKMaHKrxlMImdvvfThGs3U=; b=cH70FmuLKyXY47CG2JmD+oTEygOHrhusUKsxyKNIab2GINwy1dwD1JUKzvh0F5kOSC uuYgydI4HO1pnFHdBwO6vaOD+/DqR14gXVyg8mbhVi0MQn4hNNYcHX81LRVsCaA5l7TC 0PkgqUwt17ieDEdb/vf3YdXtvD/Tg3WSI3LUzlCiW0sR76lv4Jc8uW1qPHIkyZzIKdSa soyRW1CuwTOaKRVBxgajFYXO1XoVkXcl5dXdtvDWZGAcCPF7b9bW2a8kIKbEdntcP8GK 4yLV7v7LmAYA0JZWhRaA9tgagm3yooxXLU+Q56bbV+kcT+ASp9XxTWEAnx+HvV3ypw+j iY9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=bgDBvfDtcl0nSd0QdhX4BoKMaHKrxlMImdvvfThGs3U=; b=JWGqsNnCUNPk4W0sSs+oQUwf7VpdJ/1NM4vnMljH9w42OhsUeOQiU95nuY3p/2fteF fwUHSG8DvStchn8nMOHtFuqr5UttBlbi9A+LIWntOGhjOOKCfyO0athvspTS4Z3ot56r TI8TIYVbeoANRyKc7nh1rrHOEEQyMW1ysNCeVjRv805ASRemhz6O9/o9NTmLLNv4tEee NjXfCJU+6R9pz9NwXyWINzX2vnKO5KD/kkebihsiLZcrJbjVCcpotInhqk2EafHqXb/3 M8R6rVJH7IhJFN61L03HEEbiL2G6pjDw5OohGHxqpVwEN5UA9cFTA7jyY9dzDgV4HsdH gR7Q== X-Gm-Message-State: AD7BkJJjAZMELUyLsc4POdnlFD+ALJr/25aebXtdKoex5U8jk6gs1djI5zfiLQBNss7MLncpjcBBOCwcqmYaIA== MIME-Version: 1.0 X-Received: by 10.140.175.136 with SMTP id v130mr6994243qhv.74.1456551568387; Fri, 26 Feb 2016 21:39:28 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Fri, 26 Feb 2016 21:39:28 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <2856669.mkVhDvxH7k@ralph.baldwin.cx> References: <2800970.jY4xzTy9Hz@ralph.baldwin.cx> <2856669.mkVhDvxH7k@ralph.baldwin.cx> Date: Fri, 26 Feb 2016 22:39:28 -0700 X-Google-Sender-Auth: KuKnKPHjdmJBfPMaq9OMrRlVqfc Message-ID: Subject: Re: Wrapper API for static bus_dma allocations From: Warner Losh To: John Baldwin Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Feb 2016 05:39:29 -0000 On Fri, Feb 26, 2016 at 6:10 PM, John Baldwin wrote: > On Thursday, January 29, 2015 03:37:19 PM John Baldwin wrote: > > The bus_dma API to allocate a chunk of static DMA'able memory (e.g. for > > descriptor rings) can be a bit obtuse to use in that it require a bit of > > boilerplate to create a tag, allocate memory for the tag, then load it > to get > > the bus address. Similarly, freeing it also requires several steps. In > > addition, some of the steps are a bit subtle (e.g. the need to check for > an > > error in the bus_dma callback instead of from bus_dmamap_load()) and not > all > > drivers get those correct. > > > > To try to make this simpler I've written a little wrapper API that tries > to > > provide a single call to allocate a buffer and a single call to free a > buffer. > > Each buffer is described by a structure defined by the API, and if the > call to > > allocate a buffer succeeds, the structure contains both a pointer to the > > buffer in the kernel's address space as well as a bus address of the > buffer. > > > > In the interests of simplicity, this API does not allow the buffer to be > quite > > as fully configured as the underlying bus_dma API, instead it aims to > handle > > the most common cases that are used in most drivers. As such, it > assumes that > > the buffer must be one contiguous range of DMA address space, and the > only > > parameters that can be specified are the parent tag, the alignment of the > > buffer, the lowaddr parameter, the size of the buffer to allocate, and > the > > flags parameter that is normally passed to bus_dmamem_alloc(). I > believe that > > this should be sufficient to cover the vast majority of the drivers in > our > > tree. > > > > I've included below a patch that contains the wrapper API along with a > sample > > conversion of the ndis driver (chosen at random). If folks like this > idea I > > will update the patch to include manpage changes as well. > > > > --- //depot/vendor/freebsd/src/sys/compat/ndis/subr_ndis.c > > +++ //depot/user/jhb/cleanup/sys/compat/ndis/subr_ndis.c > > @@ -186,7 +186,6 @@ > > static ndis_status NdisMAllocateMapRegisters(ndis_handle, > > uint32_t, uint8_t, uint32_t, uint32_t); > > static void NdisMFreeMapRegisters(ndis_handle); > > -static void ndis_mapshared_cb(void *, bus_dma_segment_t *, int, int); > > static void NdisMAllocateSharedMemory(ndis_handle, uint32_t, > > uint8_t, void **, ndis_physaddr *); > > static void ndis_asyncmem_complete(device_object *, void *); > > @@ -1387,23 +1386,6 @@ > > bus_dma_tag_destroy(sc->ndis_mtag); > > } > > > > -static void > > -ndis_mapshared_cb(arg, segs, nseg, error) > > - void *arg; > > - bus_dma_segment_t *segs; > > - int nseg; > > - int error; > > -{ > > - ndis_physaddr *p; > > - > > - if (error || nseg > 1) > > - return; > > - > > - p = arg; > > - > > - p->np_quad = segs[0].ds_addr; > > -} > > - > > /* > > * This maps to bus_dmamem_alloc(). > > */ > > @@ -1443,35 +1425,17 @@ > > * than 1GB of physical memory. > > */ > > > > - error = bus_dma_tag_create(sc->ndis_parent_tag, 64, > > - 0, NDIS_BUS_SPACE_SHARED_MAXADDR, BUS_SPACE_MAXADDR, NULL, > > - NULL, len, 1, len, BUS_DMA_ALLOCNOW, NULL, NULL, > > - &sh->ndis_stag); > > + error = bus_dma_mem_create(&sh->ndis_mem, sc->ndis_parent_tag, 64, > > + NDIS_BUS_SPACE_SHARED_MAXADDR, len, BUS_DMA_NOWAIT | > BUS_DMA_ZERO); > > > > if (error) { > > free(sh, M_DEVBUF); > > return; > > } > > > > - error = bus_dmamem_alloc(sh->ndis_stag, vaddr, > > - BUS_DMA_NOWAIT | BUS_DMA_ZERO, &sh->ndis_smap); > > - > > - if (error) { > > - bus_dma_tag_destroy(sh->ndis_stag); > > - free(sh, M_DEVBUF); > > - return; > > - } > > + *vaddr = sh->ndis_mem.dma_vaddr; > > + paddr->np_quad = sh->ndis_mem.dma_baddr; > > > > - error = bus_dmamap_load(sh->ndis_stag, sh->ndis_smap, *vaddr, > > - len, ndis_mapshared_cb, (void *)paddr, BUS_DMA_NOWAIT); > > - > > - if (error) { > > - bus_dmamem_free(sh->ndis_stag, *vaddr, sh->ndis_smap); > > - bus_dma_tag_destroy(sh->ndis_stag); > > - free(sh, M_DEVBUF); > > - return; > > - } > > - > > /* > > * Save the physical address along with the source address. > > * The AirGo MIMO driver will call NdisMFreeSharedMemory() > > @@ -1482,8 +1446,6 @@ > > */ > > > > NDIS_LOCK(sc); > > - sh->ndis_paddr.np_quad = paddr->np_quad; > > - sh->ndis_saddr = *vaddr; > > InsertHeadList((&sc->ndis_shlist), (&sh->ndis_list)); > > NDIS_UNLOCK(sc); > > } > > @@ -1581,13 +1543,13 @@ > > l = sc->ndis_shlist.nle_flink; > > while (l != &sc->ndis_shlist) { > > sh = CONTAINING_RECORD(l, struct ndis_shmem, ndis_list); > > - if (sh->ndis_saddr == vaddr) > > + if (sh->ndis_mem.dma_vaddr == vaddr) > > break; > > /* > > * Check the physaddr too, just in case the driver lied > > * about the virtual address. > > */ > > - if (sh->ndis_paddr.np_quad == paddr.np_quad) > > + if (sh->ndis_mem.dma_baddr == paddr.np_quad) > > break; > > l = l->nle_flink; > > } > > @@ -1604,9 +1566,7 @@ > > > > NDIS_UNLOCK(sc); > > > > - bus_dmamap_unload(sh->ndis_stag, sh->ndis_smap); > > - bus_dmamem_free(sh->ndis_stag, sh->ndis_saddr, sh->ndis_smap); > > - bus_dma_tag_destroy(sh->ndis_stag); > > + bus_dma_mem_free(&sh->ndis_mem); > > > > free(sh, M_DEVBUF); > > } > > --- //depot/vendor/freebsd/src/sys/dev/if_ndis/if_ndisvar.h > > +++ //depot/user/jhb/cleanup/sys/dev/if_ndis/if_ndisvar.h > > @@ -66,10 +66,7 @@ > > > > struct ndis_shmem { > > list_entry ndis_list; > > - bus_dma_tag_t ndis_stag; > > - bus_dmamap_t ndis_smap; > > - void *ndis_saddr; > > - ndis_physaddr ndis_paddr; > > + struct bus_dmamem ndis_mem; > > }; > > > > struct ndis_cfglist { > > --- //depot/vendor/freebsd/src/sys/kern/subr_bus_dma.c > > +++ //depot/user/jhb/cleanup/sys/kern/subr_bus_dma.c > > @@ -540,3 +540,66 @@ > > > > return (0); > > } > > + > > +struct bus_dma_mem_cb_data { > > + struct bus_dmamem *mem; > > + int error; > > +}; > > + > > +static void > > +bus_dma_mem_cb(void *arg, bus_dma_segment_t *segs, int nseg, int error) > > +{ > > + struct bus_dma_mem_cb_data *d; > > + > > + d = arg; > > + d->error = error; > > + if (error) > > + return; > > + d->mem->dma_baddr = segs[0].ds_addr; > > +} > > + > > +int > > +bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > > + bus_size_t alignment, bus_addr_t lowaddr, bus_size_t len, int flags) > > +{ > > + struct bus_dma_mem_cb_data d; > > + int error; > > + > > + bzero(mem, sizeof(*mem)); > > + error = bus_dma_tag_create(parent, alignment, 0, lowaddr, > > + BUS_SPACE_MAXADDR, NULL, NULL, len, 1, len, 0, NULL, NULL, > > + &mem->dma_tag); > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + error = bus_dmamem_alloc(mem->dma_tag, &mem->dma_vaddr, flags, > > + &mem->dma_map); > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + d.mem = mem; > > + error = bus_dmamap_load(mem->dma_tag, mem->dma_map, > mem->dma_vaddr, len, > > + bus_dma_mem_cb, &d, BUS_DMA_NOWAIT); > > + if (error == 0) > > + error = d.error; > > + if (error) { > > + bus_dma_mem_free(mem); > > + return (error); > > + } > > + return (0); > > +} > > + > > +void > > +bus_dma_mem_free(struct bus_dmamem *mem) > > +{ > > + > > + if (mem->dma_baddr != 0) > > + bus_dmamap_unload(mem->dma_tag, mem->dma_map); > > + if (mem->dma_vaddr != NULL) > > + bus_dmamem_free(mem->dma_tag, mem->dma_vaddr, > mem->dma_map); > > + if (mem->dma_tag != NULL) > > + bus_dma_tag_destroy(mem->dma_tag); > > + bzero(mem, sizeof(*mem)); > > +} > > --- //depot/vendor/freebsd/src/sys/sys/bus_dma.h > > +++ //depot/user/jhb/cleanup/sys/sys/bus_dma.h > > @@ -337,4 +337,29 @@ > > > > #endif /* __sparc64__ */ > > > > +/* > > + * A wrapper API to simplify management of static mappings. > > + */ > > + > > +struct bus_dmamem { > > + bus_dma_tag_t dma_tag; > > + bus_dmamap_t dma_map; > > + void *dma_vaddr; > > + bus_addr_t dma_baddr; > > +}; > > + > > +/* > > + * Allocate a mapping. On success, zero is returned and the 'dma_vaddr' > > + * and 'dma_baddr' fields are populated with the virtual and bus > addresses, > > + * respectively, of the mapping. > > + */ > > +int bus_dma_mem_create(struct bus_dmamem *mem, bus_dma_tag_t parent, > > + bus_size_t alignment, bus_addr_t lowaddr, > > + bus_size_t len, int flags); > > + > > +/* > > + * Release a mapping created by bus_dma_mem_create(). > > + */ > > +void bus_dma_mem_free(struct bus_dmamem *mem); > > + > > #endif /* _BUS_DMA_H_ */ > > Ping. The last time I brought this up we ended up off in the weeds a bit > about changes to the bus dma API in general. However, I think that even if > we reduce the number of args to bus_dma_create_tag you are still left with > managing a tag per static allocation etc. I'm working on porting a driver > today where I basically just copied this into the driver directly rather > than having to implement it all by hand for the umpteenth time. Are folks > seriously opposed to having a single function you can call to allocate a > static DMA mapping I have no objections to this. Warner