From owner-freebsd-arch@freebsd.org Mon Feb 22 01:42:50 2016
Return-Path: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
Subject: RF_CACHEABLE flag
From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: "freebsd-arch@freebsd.org" <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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <kostikbel@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject: Re: RF_CACHEABLE flag
Message-ID: <20160222121836.GH91220@kib.kiev.ua>
References: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
<20160222121836.GH91220@kib.kiev.ua>
Date: Tue, 23 Feb 2016 14:19:57 -0600
X-Google-Sender-Auth: JECrNBcx1fAx1i32W-QCfH9M26U
Message-ID: <CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com>
Subject: Re: RF_CACHEABLE flag
From: Justin Hibbits <jrh29@alumni.cwru.edu>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: "freebsd-arch@freebsd.org" <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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Feb 2016 20:19:58 -0000
On Mon, Feb 22, 2016 at 6:18 AM, Konstantin Belousov
<kostikbel@gmail.com> 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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <kostikbel@gmail.com>
To: Justin Hibbits <jrh29@alumni.cwru.edu>
Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org>
Subject: Re: RF_CACHEABLE flag
Message-ID: <20160224102754.GK91220@kib.kiev.ua>
References: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
<20160222121836.GH91220@kib.kiev.ua>
<CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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: <CAHSQbTA5A3uSDT143e3yWmfzWZyOCDJ4GSo6JO2NiLc_VAKoYg@mail.gmail.com>
<20160222121836.GH91220@kib.kiev.ua>
<CAHSQbTDZVpNU0WsXSHM8yuDqn_5vmy9Ox0fnLZLb2NJfoC7Exg@mail.gmail.com>
<20160224102754.GK91220@kib.kiev.ua>
Date: Wed, 24 Feb 2016 09:14:17 -0800
Message-ID: <CAJ-VmomUxb7nR7cyg58zHVrVP3MB2JLLebWJPf7kB0F7NDpu6A@mail.gmail.com>
Subject: Re: RF_CACHEABLE flag
From: Adrian Chadd <adrian.chadd@gmail.com>
To: Konstantin Belousov <kostikbel@gmail.com>
Cc: Justin Hibbits <jrh29@alumni.cwru.edu>,
"freebsd-arch@freebsd.org" <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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Feb 2016 17:14:22 -0000
On 24 February 2016 at 02:27, Konstantin Belousov <kostikbel@gmail.com> 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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <arch@mailman.ysv.freebsd.org>; 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 <arch@FreeBSD.org>; 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 <arch@FreeBSD.org>; 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 <arch@FreeBSD.org>; 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 <arch@freebsd.org>;
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 <bdrewery@FreeBSD.org>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <arch@mailman.ysv.freebsd.org>; 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 <bdrewery@freebsd.org>
CC: <arch@freebsd.org>, <sjg@juniper.net>
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 <bdrewery@freebsd.org>
message dated "Fri, 26 Feb 2016 14:10:48 -0800."
From: "Simon J. Gerraty" <sjg@juniper.net>
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: <CY1PR05MB194862ED49903AB71E64C647AAA70@CY1PR05MB1948.namprd05.prod.outlook.com>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 23:20:21 -0000
Bryan Drewery <bdrewery@freebsd.org> 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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <arch@mailman.ysv.freebsd.org>; 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" <sjg@juniper.net>
References: <56D0CD68.606@FreeBSD.org> <77472.1456528808@kaos.jnpr.net>
Cc: arch@freebsd.org
From: Bryan Drewery <bdrewery@FreeBSD.org>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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 <bdrewery@freebsd.org> 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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <arch@mailman.ysv.freebsd.org>; 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 <bdrewery@FreeBSD.org>
CC: <arch@FreeBSD.org>, <sjg@juniper.net>
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 <bdrewery@FreeBSD.org>
message dated "Fri, 26 Feb 2016 15:30:31 -0800."
From: "Simon J. Gerraty" <sjg@juniper.net>
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: <BY1PR0501MB16089AB3133C70F68589B498AAA70@BY1PR0501MB1608.namprd05.prod.outlook.com>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 23:47:15 -0000
Bryan Drewery <bdrewery@FreeBSD.org> 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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; Fri, 26 Feb 2016 21:13:41 -0500 (EST)
From: John Baldwin <jhb@freebsd.org>
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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=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: <owner-freebsd-arch@freebsd.org>
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 <freebsd-arch@mailman.ysv.freebsd.org>;
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 <freebsd-arch@freebsd.org>; 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 <freebsd-arch@freebsd.org>; 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: <CANCZdfq7P+YOgCcsN7AJO+57mnPVstycSOXiBN0gSar0X83ThQ@mail.gmail.com>
Subject: Re: Wrapper API for static bus_dma allocations
From: Warner Losh <imp@bsdimp.com>
To: John Baldwin <jhb@freebsd.org>
Cc: "freebsd-arch@freebsd.org" <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 <freebsd-arch.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch/>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Feb 2016 05:39:29 -0000
On Fri, Feb 26, 2016 at 6:10 PM, John Baldwin <jhb@freebsd.org> 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