From owner-freebsd-arch@freebsd.org Sun Feb 10 09:15:48 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7948C14E6778 for ; Sun, 10 Feb 2019 09:15:48 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 723856E389 for ; Sun, 10 Feb 2019 09:15:47 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-pf1-x42a.google.com with SMTP id u6so3779625pfh.11 for ; Sun, 10 Feb 2019 01:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=T8lYjB9VnsDti8oZUcCn60UafsiLjnL9vPEqBjxgJao=; b=LPnBLcvI/+FjpN6YghmCu66BANn6KY4u7ez20iFPVqINcnUSnqRYethYqnIE4Dcw77 D0tkCmrcA1ZFNCSD971gG9RabyYKpju1+Q4SZ/C4dTWrh1RTaKzmxdVu6XeZ/V089PW+ ye9bu2VL9yJV798m2PqfHNuvmMoBjTnp54Hwwax/9Rr8obxuAbh8LGf1I70pE0W6sUAh QKGlUPT7ptVD0o6bmjlCG3y/0nL1TkKD0vD/lIAzywZQFAs5IupFaTi+bLZzl0OmxMV3 JwI37AiEkr44nquVpcsS6xn4sssAx8eeikWU8bdhBxXbbNLgjFVJjk46E0A96GfTt3De KxVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=T8lYjB9VnsDti8oZUcCn60UafsiLjnL9vPEqBjxgJao=; b=Mzer/oe61trbdDXS5fEuVH0jsMmsRDBVfzkXxIq55T65C12MDCoeam9Pbq9f0Zaatt 7hPd7dKIBor7GAHh1VgMDnmbiXVC4lkt9kWy5WbhUZZ86brRP6keS/wpMAzFMPfxRtkb GGpy1xH4Ku4+uOB4qfceVIxG7tdyurUJKXLzwq0KDOMJIhFvoHP3srRlrc5CkFRPwx4u HdMXQEyCapGrDi4kShbV8sgO97S56GsnEPhEqQRK1Yd1O/xoP0AS1xO8mgoJr3ODcyiq 0wG09wEFzRY4uQNGo5kk+rAHziMn75Olq21nOACnr8tVg4nbG1n2KKHJ5LuHEZeyfXUt 5RUA== X-Gm-Message-State: AHQUAubF2YjYx09cUCJj/m2gsOJX4KlJYd8+QU2rY/hrE7Ixr46iEvGw rp17upsSklZmep5DW/Tu6TgaF+8= X-Google-Smtp-Source: AHgI3Ia4ZCufP4sgY0VLk4lgmu8Qcehbr+ezlU+uGmDf2RzMpQUlYCsbdhAWCSeCM1pSEIwUSFGC5g== X-Received: by 2002:a63:d84e:: with SMTP id k14mr20713474pgj.436.1549790146142; Sun, 10 Feb 2019 01:15:46 -0800 (PST) Received: from [192.168.1.2] (c-67-188-30-11.hsd1.ca.comcast.net. [67.188.30.11]) by smtp.googlemail.com with ESMTPSA id g20sm12007215pfg.85.2019.02.10.01.15.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Feb 2019 01:15:45 -0800 (PST) To: FreeBSD Arch From: Jason Harmening Subject: Any desire for a more flexible bus_dmamem_alloc variant ? Message-ID: Date: Sun, 10 Feb 2019 01:13:32 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 723856E389 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=LPnBLcvI; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jasonharmening@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) smtp.mailfrom=jasonharmening@gmail.com X-Spamd-Result: default: False [-5.61 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.92)[-0.922,0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[a.2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.68)[ip: (-8.90), ipnet: 2607:f8b0::/32(-2.46), asn: 15169(-1.95), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2019 09:15:48 -0000 Hi everyone, It's really bugged me for years that bus_dmamem_alloc() just uses the tag's maximum size instead of allowing a size to be passed in. I got reminded of this again recently when looking over some busdma code. I know others have voiced this complaint in the past: https://lists.freebsd.org/pipermail/freebsd-current/2012-July/035281.html I used to work on an out-of-tree driver that could've benefited from something like this. It also seems like the benefits of using bus_dmamem_alloc() to always do the optimal thing instead of, say, rolling your own using kmem_alloc_[attr|contig] will increase as we adopt support for IOMMUs. I'd like to see if there's any interest in adding a bus_dmamem_alloc_attr() KPI that takes both a size and vm_memattr_t. Are there any potential in-tree consumers of such a thing? --Jason From owner-freebsd-arch@freebsd.org Mon Feb 11 09:43:52 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69F8514D062F for ; Mon, 11 Feb 2019 09:43:52 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) 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 E125E8C667 for ; Mon, 11 Feb 2019 09:43:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id A562114D062E; Mon, 11 Feb 2019 09:43:51 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93CE614D062C for ; Mon, 11 Feb 2019 09:43:51 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 8526B8C666 for ; Mon, 11 Feb 2019 09:43:50 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id F39F02025617 for ; Mon, 11 Feb 2019 09:43:42 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x1B9hgmm092709 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 11 Feb 2019 09:43:42 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x1B9hgKD092708; Mon, 11 Feb 2019 09:43:42 GMT (envelope-from phk) To: arch@freebsd.org Subject: switch to non-zero PTHREAD_*_INITIALIZER From: Poul-Henning Kamp MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <92706.1549878222.1@critter.freebsd.dk> Date: Mon, 11 Feb 2019 09:43:42 +0000 Message-ID: <92707.1549878222@critter.freebsd.dk> X-Rspamd-Queue-Id: 8526B8C666 X-Spamd-Bar: +++ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [3.13 / 15.00]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.50)[0.499,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[freebsd.dk]; MX_GOOD(-0.01)[phk.freebsd.dk]; NEURAL_SPAM_LONG(0.30)[0.302,0]; NEURAL_SPAM_MEDIUM(0.90)[0.897,0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; RCVD_NO_TLS_LAST(0.10)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; IP_SCORE(0.14)[ip: (0.21), ipnet: 130.225.0.0/16(0.10), asn: 1835(0.39), country: EU(-0.00)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 09:43:52 -0000 Right now most of our PTHREAD_*_INITIALIZER macros are defined as NULL. This is a bad choice from a code quality point of view, because it means that pthread_t my_mutex; and pthread_t my_mutes = PTHREAD_MUTEX_INITIALIZER; act the same, which they are not. I suggest that we should change the macros to a non-NULL value, and add a check for NULL values which emit a warning about the lack of initialization. Comments ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-arch@freebsd.org Mon Feb 11 10:38:17 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30F3D14D1E0E for ; Mon, 11 Feb 2019 10:38:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 A43698E24C for ; Mon, 11 Feb 2019 10:38:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6249114D1E09; Mon, 11 Feb 2019 10:38:16 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50C1F14D1E08 for ; Mon, 11 Feb 2019 10:38:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA09D8E245 for ; Mon, 11 Feb 2019 10:38:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1BAc8TG090770 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 11 Feb 2019 12:38:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1BAc8TG090770 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1BAc7je090769; Mon, 11 Feb 2019 12:38:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 11 Feb 2019 12:38:07 +0200 From: Konstantin Belousov To: Poul-Henning Kamp Cc: arch@freebsd.org Subject: Re: switch to non-zero PTHREAD_*_INITIALIZER Message-ID: <20190211103807.GX24863@kib.kiev.ua> References: <92707.1549878222@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <92707.1549878222@critter.freebsd.dk> User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 10:38:17 -0000 On Mon, Feb 11, 2019 at 09:43:42AM +0000, Poul-Henning Kamp wrote: > Right now most of our PTHREAD_*_INITIALIZER macros are defined as NULL. > > This is a bad choice from a code quality point of view, because it means > that > > pthread_t my_mutex; > > and > > pthread_t my_mutes = PTHREAD_MUTEX_INITIALIZER; > > act the same, which they are not. > > I suggest that we should change the macros to a non-NULL value, and > add a check for NULL values which emit a warning about the lack of > initialization. > > Comments ? This would make the startup (or more) of current binaries too noisy and perhaps even break the applications that depend on specific output from the subordinate processes. I wanted to reorganize static initializizers for some time, esp. to add specific initializers like RECURSIVE_NP and similar. This requires more changes in libthr, particular to the shared and destroyed mutexes canary values, which is quite delicate thing to do. So far I did not spend time on this. From owner-freebsd-arch@freebsd.org Mon Feb 11 11:06:27 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B32B314D28B3 for ; Mon, 11 Feb 2019 11:06:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) 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 1B6F98F273 for ; Mon, 11 Feb 2019 11:06:27 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id C974714D28B2; Mon, 11 Feb 2019 11:06:26 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B706D14D28B0 for ; Mon, 11 Feb 2019 11:06:26 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 4EADB8F272 for ; Mon, 11 Feb 2019 11:06:25 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id DC668202561C; Mon, 11 Feb 2019 11:06:24 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x1BB6OaJ093028 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 11 Feb 2019 11:06:24 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x1BB6OIi093027; Mon, 11 Feb 2019 11:06:24 GMT (envelope-from phk) To: Konstantin Belousov cc: arch@freebsd.org Subject: Re: switch to non-zero PTHREAD_*_INITIALIZER In-reply-to: <20190211103807.GX24863@kib.kiev.ua> From: "Poul-Henning Kamp" References: <92707.1549878222@critter.freebsd.dk> <20190211103807.GX24863@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93025.1549883184.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Feb 2019 11:06:24 +0000 Message-ID: <93026.1549883184@critter.freebsd.dk> X-Rspamd-Queue-Id: 4EADB8F272 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.97)[-0.969,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 11:06:27 -0000 -------- In message <20190211103807.GX24863@kib.kiev.ua>, Konstantin Belousov write= s: >On Mon, Feb 11, 2019 at 09:43:42AM +0000, Poul-Henning Kamp wrote: >> Right now most of our PTHREAD_*_INITIALIZER macros are defined as NULL. >> = >> This is a bad choice from a code quality point of view, because it mean= s >> that >> = >> pthread_t my_mutex; >> = >> and >> = >> pthread_t my_mutes =3D PTHREAD_MUTEX_INITIALIZER; >> = >> act the same, which they are not. >> = >> I suggest that we should change the macros to a non-NULL value, and >> add a check for NULL values which emit a warning about the lack of >> initialization. >> = >> Comments ? > >This would make the startup (or more) of current binaries too noisy and >perhaps even break the applications that depend on specific output from >the subordinate processes. Right, we probably should make it tweakable with something like /etc/mallo= c.conf. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Mon Feb 11 13:06:44 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7AC6614D6788 for ; Mon, 11 Feb 2019 13:06:44 +0000 (UTC) (envelope-from deischen@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 172F46C997 for ; Mon, 11 Feb 2019 13:06:44 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id CC30814D6784; Mon, 11 Feb 2019 13:06:43 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B96FE14D6783 for ; Mon, 11 Feb 2019 13:06:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5E63B6C994 for ; Mon, 11 Feb 2019 13:06:43 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id x1BD5XHx061910; Mon, 11 Feb 2019 08:05:33 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Mon, 11 Feb 2019 08:05:33 -0500 (EST) Date: Mon, 11 Feb 2019 08:05:33 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Poul-Henning Kamp cc: arch@freebsd.org Subject: Re: switch to non-zero PTHREAD_*_INITIALIZER In-Reply-To: <92707.1549878222@critter.freebsd.dk> Message-ID: References: <92707.1549878222@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 5E63B6C994 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.96 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 13:06:44 -0000 On Mon, 11 Feb 2019, Poul-Henning Kamp wrote: > Right now most of our PTHREAD_*_INITIALIZER macros are defined as NULL. > > This is a bad choice from a code quality point of view, because it means > that > > pthread_t my_mutex; > > and > > pthread_t my_mutes = PTHREAD_MUTEX_INITIALIZER; > > act the same, which they are not. > > I suggest that we should change the macros to a non-NULL value, and > add a check for NULL values which emit a warning about the lack of > initialization. > > Comments ? You'll get warnings from anything that hasn't be rebuilt with the new initializers, including other languages that have overlays to the same C structures (well, really ours are pointers to structs). I'm not really against this, but I'd rather see our mutex, condvar, etc, be real structs instead of pointers to structs. This would hopefully get rid of the whole malloc mess inside libthr and simplify pthread_XXX_setpshared(). I'd think that we've evolved the pthread API enough to pick some large enough storage size for our structs such that we won't have to change it again. Of course, even with versioned libraries, this change would probably require a library version bump. -- DE From owner-freebsd-arch@freebsd.org Mon Feb 11 17:34:26 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF3C114DE47A for ; Mon, 11 Feb 2019 17:34:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7120580F13; Mon, 11 Feb 2019 17:34:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 1B67D97D2; Mon, 11 Feb 2019 17:34:25 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Any desire for a more flexible bus_dmamem_alloc variant ? To: Jason Harmening , FreeBSD Arch References: From: John Baldwin Openpgp: preference=signencrypt Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <7d214dbe-b873-e626-776a-efdf2ac693b7@FreeBSD.org> Date: Mon, 11 Feb 2019 09:34:23 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 7120580F13 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.997,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; NEURAL_HAM_SHORT(-0.97)[-0.968,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 17:34:26 -0000 On 2/10/19 1:13 AM, Jason Harmening wrote: > Hi everyone, > > It's really bugged me for years that bus_dmamem_alloc() just uses the > tag's maximum size instead of allowing a size to be passed in. I got > reminded of this again recently when looking over some busdma code. > > I know others have voiced this complaint in the past: > https://lists.freebsd.org/pipermail/freebsd-current/2012-July/035281.html > > I used to work on an out-of-tree driver that could've benefited from > something like this. It also seems like the benefits of using > bus_dmamem_alloc() to always do the optimal thing instead of, say, > rolling your own using kmem_alloc_[attr|contig] will increase as we > adopt support for IOMMUs. > > I'd like to see if there's any interest in adding a > bus_dmamem_alloc_attr() KPI that takes both a size and vm_memattr_t. > Are there any potential in-tree consumers of such a thing? I have this review I need to rebase and write the manpage bits for. While it still ties the the size to the tag, it mostly hides the individual tag: https://reviews.freebsd.org/D5704 -- John Baldwin                                                                              From owner-freebsd-arch@freebsd.org Tue Feb 12 00:52:15 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 281BC14E8D4C for ; Tue, 12 Feb 2019 00:52:15 +0000 (UTC) (envelope-from cse.cem@gmail.com) 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 90FDC91AF0 for ; Tue, 12 Feb 2019 00:52:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4A94414E8D4B; Tue, 12 Feb 2019 00:52:14 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2671714E8D4A for ; Tue, 12 Feb 2019 00:52:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f182.google.com (mail-it1-f182.google.com [209.85.166.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 420E991AEA for ; Tue, 12 Feb 2019 00:52:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f182.google.com with SMTP id b5so3216065iti.2 for ; Mon, 11 Feb 2019 16:52:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:from:date:message-id :subject:to; bh=FI056E7OgijNKE8StvaHP1JvPLnIXVViTZlA6fZbCF0=; b=T9lnjAxqZgNg/9G73DLh6LOZ9tWDq6+5dWbcsEIFNUuLyb8aBxbAImE5LLwMNSrgyh tsndZKlsGgYFs9tpgib29iyEq0tFqf4w7pB+P9eme40WnAq7lbY24bt590M7TxdkgvFj YenGDCZ/snGy1Zku2whpeE6bEh22D/tsecBCKRnxtuoqv0iPlJn0gaZFo21H72Q9XEX1 qLhufGe/MdIl25uSC0uB3jFXv6Li45/1/LWSwfBP3PMbjf0LCxnEXErcBXGqFE+0n+xO G4cd3mnjJHohyTRkBkAZ0zXQPRQ/YHiiWThxg5BBXWjUZZVky9biW5WlGWnQEqODqdqH hd4A== X-Gm-Message-State: AHQUAuaSq3qCa1nU9Zl55xmQ/2oiejPIXW3EsJsPN9t8HxdULLEnoZTQ gEb9yyv314dPbWxruyEcOb+YbtSe X-Google-Smtp-Source: AHgI3IY0pD69rig1cBWF05uOoddEDdAeWuJwsEUNWKF22SAjeqpu+42vI9h1GszD3MbXm3f+wBFV3w== X-Received: by 2002:a6b:b241:: with SMTP id b62mr555339iof.261.1549932731780; Mon, 11 Feb 2019 16:52:11 -0800 (PST) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com. [209.85.166.177]) by smtp.gmail.com with ESMTPSA id p2sm5238736iog.84.2019.02.11.16.52.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Feb 2019 16:52:11 -0800 (PST) Received: by mail-it1-f177.google.com with SMTP id v72so3260578itc.0 for ; Mon, 11 Feb 2019 16:52:11 -0800 (PST) X-Received: by 2002:a24:2f82:: with SMTP id j124mr481287itj.166.1549932730892; Mon, 11 Feb 2019 16:52:10 -0800 (PST) MIME-Version: 1.0 Reply-To: cem@freebsd.org From: Conrad Meyer Date: Mon, 11 Feb 2019 16:52:00 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: RFC: What to do about VOP_INACTIVE? To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 420E991AEA X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.182 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; TO_DOM_EQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[182.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-2.78)[ip: (-8.12), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.96), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 00:52:15 -0000 Hello, The nominal return type of the VOP_INACTIVE vnode method is 'int', but in practice any error returned is silently discarded. The only caller is vinactive(), which is also a void routine. vinactive ignores the return value of VOP_INACTIVE(). (vinactive tends to be called by other void routines, like vput(), so propagating an error up the stack is non-trivial.) In practice, most filesystems in the kernel unconditionally return zero for INACTIVE. The exceptions are: msdosfs, ext2fs, nandfs, and (notably) ufs. The problem (as I see it) is that the return type makes it appear that INACTIVE is allowed to fail, but it is not. One important ramification of this is that interruptible sleeps in INACTIVE are basically not permitted. This seems problematic because INACTIVE is invoked as part of close(2), and we can potentially block that user process indefinitely when the kernel filesystem is stalled on a network resource, or something like a FUSE userspace filesystem (which can also access network resources). Can we live with the current behavior (INACTIVE cannot fail)? In that case, I think we should change its return type to void to match. Thoughts? Thanks, Conrad From owner-freebsd-arch@freebsd.org Tue Feb 12 01:33:43 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0413614EC823 for ; Tue, 12 Feb 2019 01:33:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) 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 6C4A094CE0 for ; Tue, 12 Feb 2019 01:33:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 2B11314EC81A; Tue, 12 Feb 2019 01:33:42 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E498B14EC819 for ; Tue, 12 Feb 2019 01:33:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660085.outbound.protection.outlook.com [40.107.66.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6FC8494CDE; Tue, 12 Feb 2019 01:33:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM (52.132.89.15) by QB1PR01MB3314.CANPRD01.PROD.OUTLOOK.COM (52.132.86.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.21; Tue, 12 Feb 2019 01:33:40 +0000 Received: from QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c]) by QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM ([fe80::609b:1ecd:c908:d44c%5]) with mapi id 15.20.1601.023; Tue, 12 Feb 2019 01:33:40 +0000 From: Rick Macklem To: "freebsd-arch@freebsd.org" , "cem@freebsd.org" Subject: Re: What to do about VOP_INACTIVE? Thread-Topic: What to do about VOP_INACTIVE? Thread-Index: AQHUwm02MzmT3Pcfhk2kEOAgv/qJlaXbXsEV Date: Tue, 12 Feb 2019 01:33:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; QB1PR01MB3314; 6:Bvc8C7s1N9XEBcFpNkkhHAGuC8MNWNaQrfyh0OmgTOMFvtg2llUDDz98/H8hTzU0+U6AznBYTzHBhLnf4ME6zo1+e3cvvAtiCTaxvEUvwzlBpVt+DKha1jaQy5WUZ6Ym2RgGWGwu4kzlthzM9wgCH32lnrCKTefIWgWy0UAjZDLsAJVG+eEvA4lPMUz8KHHNBLSpG6V0qwl2JsxAWGTfOSatbeyB2UGvijiu7PH2pwxyKi4gXxnulK5ci2TP+fAOjhexRs5g75QfOS988tOxfjuyI94uXm/iTslUURiKeGdPAmzBv1KNhROrej05d8eVEluWGmvCuuQno+o364QxqeU9snENgIHOFF7qCGw5yM+f2Z8U4HUlNQttq9JPG/xx/oL64Imn5SC+0W/WzyV149OmRxzjh+MZMDopLDASEgpQOm2bDTnr67ySJ6ktADBZhQG5ri0+YBsLN9jWHw1x7g==; 5:lRmQggZUrq0V89i+KC1Dh5jIC/wMrx/63tlGPbriNSzg4nZ4nZtsIq7kTVzkQ1FFpv9zZLmGCNsqbB6D9v1IS/tY3R329rzZzN3XyuMWTwfxCjbzDT5gHYj5y9QzynGmqLzCgz6iMUaAgim7pGWe8LdGkwhS4oaNWk3J9uXq4u/WMnuWGMpUr6wfR87LkB5ProniX7l3xe+7bMVksUCuhA==; 7:93OqLvawxRIxZfOi7gYCBTEZnmDQarMrhqOQC/pv8pTUyzPC9d7Sx4sru71uyoIPZsfYFYCU5lK3jF9aT3HgE+MxmDeflfkw2bvsyPdlBjl7ZmfvW+79pRItNZYzWTQr2vknSYCJnJZJ7qQDrBhNNw== x-ms-office365-filtering-correlation-id: 2af6dbad-ed82-4aa3-aedb-08d6908a1dee x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:QB1PR01MB3314; x-ms-traffictypediagnostic: QB1PR01MB3314: x-microsoft-antispam-prvs: x-forefront-prvs: 0946DC87A1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(39860400002)(136003)(376002)(199004)(189003)(71200400001)(8676002)(81166006)(316002)(8936002)(7696005)(74316002)(186003)(229853002)(486006)(81156014)(74482002)(478600001)(68736007)(446003)(476003)(11346002)(110136005)(55016002)(9686003)(71190400001)(2906002)(14454004)(6436002)(105586002)(46003)(25786009)(102836004)(106356001)(14444005)(76176011)(256004)(6246003)(305945005)(2501003)(450100002)(97736004)(786003)(6506007)(33656002)(99286004)(53936002)(86362001)(491001); DIR:OUT; SFP:1101; SCL:1; SRVR:QB1PR01MB3314; H:QB1PR01MB3537.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fi9vmlPow5GMgTPIlgcI2NqROScFzGuUu3CMOdoxrG3uzR8sfqGvko+rVArJL3aoRGPQ8pQ81OY2qV1ErUUg8jmYS3x+tekupXi3uKiWuh00qYWJy4ri5DaxrZ7+A2oVRfA36i58TwXodOuBLBTcNj7NDcQHGS7nmkfXu04DrtNn2nU8PIbJ564euNe5tcYen+ZrLLodMQRGBFmHBpp0YDrJoWofhoe+vSq6U93Kt3EPVqH5Aft3FqVmdUW/LS6TGBiKdvCtPPJQyMgtAjVlYdUyBLx/jlYsPyuAeock8ZICwlO4zCePiV9P9SCVrYlaIamoMnhpiPkWn0IAO+d/d2U+X4pofkPBt7vF6NjKiEB/u6qTxJrMIfYFwu3wHurAiP7s/v69hOSIcywgIpT0Xt844pRRk+IXImVP7BVZgI0= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 2af6dbad-ed82-4aa3-aedb-08d6908a1dee X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2019 01:33:40.0511 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3314 X-Rspamd-Queue-Id: 6FC8494CDE X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.95 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; NEURAL_HAM_SHORT(-0.96)[-0.957,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 01:33:43 -0000 Conrad Meyer wrote: >The nominal return type of the VOP_INACTIVE vnode method is 'int', but >in practice any error returned is silently discarded. > >The only caller is vinactive(), which is also a void routine. >vinactive ignores the return value of VOP_INACTIVE(). (vinactive >tends to be called by other void routines, like vput(), so propagating >an error up the stack is non-trivial.) > >In practice, most filesystems in the kernel unconditionally return >zero for INACTIVE. The exceptions are: msdosfs, ext2fs, nandfs, and >(notably) ufs. > >The problem (as I see it) is that the return type makes it appear that >INACTIVE is allowed to fail, but it is not. One important >ramification of this is that interruptible sleeps in INACTIVE are >basically not permitted. > >This seems problematic because INACTIVE is invoked as part of >close(2), and we can potentially block that user process indefinitely >when the kernel filesystem is stalled on a network resource, or >something like a FUSE userspace filesystem (which can also access >network resources). > >Can we live with the current behavior (INACTIVE cannot fail)? In that >case, I think we should change its return type to void to match. > >Thoughts? Well Kostik is the expert, but my understanding is that a file system canno= t assume that VOP_INACTIVE() will actually be called for a vnode. As such, th= e file system needs to do anything it does in its VOP_INACTIVE() in its VOP_R= ECLAIM() as well, if it must be done before the vnode is reused. As such, a failed VOP_INACTIVE() doesn't seem to be meaningful, since it mi= ght not get called at all? Having said that, making sure file system implementors know the above seems more important than whether it returns int vs void. (ie. Returning 0 seems harmless to me and may be useful in the future. Sinc= e changing the VFS/VOP interface can only be done for major releases and req= uires all file systems to be changed, I leave it, but this is not a strong opini= on.) rick From owner-freebsd-arch@freebsd.org Tue Feb 12 04:52:12 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D0E114D55FE for ; Tue, 12 Feb 2019 04:52:12 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2D026FBE2; Tue, 12 Feb 2019 04:52:10 +0000 (UTC) (envelope-from jason.harmening@gmail.com) Received: by mail-it1-x131.google.com with SMTP id o131so838750itc.5; Mon, 11 Feb 2019 20:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NKeiTm0UaF7YOn2jng8efU2h1pXd9j5/SW1iHEJxMjU=; b=TtY1ZWeYie2FrXXhucI2Gbe9vDWv9EBWzb4sm3yMaJIo0IXAmdOZO4eqbXYefEH11t ueViKncOlBIyW6jZ+XtgQtDrH7D1+gnjYSz7DjHSHtSuUCqeIFm+vnUDsgAj/D/bcYmb YJKcLz5q13yYEVynJN0IkhQkIJBCaZ83dqFAdOgt/mpinMgDwpd37qHL4ZtLv9CsPNyY QtVmVbxb2Bo2hq16b3gQzu9xmpglk1a77W40Lbmn+kNG68gumU3Vn7kZcKL7UNQg4bUR 4Q8U1FroWZ+K/99rxiPc6S0Sg+gnSeYU8DCH0lLXac6WMg+0clIYAZzWRNWYu7OQunXh QIvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NKeiTm0UaF7YOn2jng8efU2h1pXd9j5/SW1iHEJxMjU=; b=CfxQkNdi/IXyN6Otx/RAEXQREuh1uKm2/nzD9FxZWtcmq99ImpeDOfTn5NvMgAigKV XB5n58PjsI0UBE059257eNEbzOznk36Us2ynlxFAnAa59rdChcK2/ukMTYswB7AJPY1O 6YxYdN2FEQSQoNGcQVm2tm+DpegzF6fOzC+Md16NDMpWXuVtdiLzQL0tUGgRcNDTCQ6P 5M+0uTDQ1DGcz1mWKrMkeWI5/yKDsupFAAHkbzBF7MJxdfA0BVXusxC2rSq0ubqf1g5U 992cPwc9i2tBcEKtC1o6Z0MWDUrNatXUv8LVVfyDDCA8JfsbprI36YiMr/CblYBHvQeg qHFA== X-Gm-Message-State: AHQUAubzueDg/p9rKEJNt4ZtMF4YmPrRBZs94IMmsUkljWzjmj8/L8BK MadXGQauXhCnTreIIGGKOT0SL54HqpHqmRA0RAIt X-Google-Smtp-Source: AHgI3IZGP9r7g1PU0pIpwMdACp6GTQoTD2XqlYZbuuEy6irtsIqNuID1H9qVXE0UDOqgZyWj5X/75bgB0ISOL2GrQ3A= X-Received: by 2002:a24:32c7:: with SMTP id j190mr921180ita.144.1549947129943; Mon, 11 Feb 2019 20:52:09 -0800 (PST) MIME-Version: 1.0 References: <7d214dbe-b873-e626-776a-efdf2ac693b7@FreeBSD.org> In-Reply-To: <7d214dbe-b873-e626-776a-efdf2ac693b7@FreeBSD.org> From: Jason Harmening Date: Mon, 11 Feb 2019 20:51:59 -0800 Message-ID: Subject: Re: Any desire for a more flexible bus_dmamem_alloc variant ? To: John Baldwin Cc: FreeBSD Arch X-Rspamd-Queue-Id: E2D026FBE2 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TtY1ZWeY; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of jasonharmening@gmail.com designates 2607:f8b0:4864:20::131 as permitted sender) smtp.mailfrom=jasonharmening@gmail.com X-Spamd-Result: default: False [-5.05 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.51)[-0.514,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE(-2.52)[ip: (-8.08), ipnet: 2607:f8b0::/32(-2.50), asn: 15169(-1.96), country: US(-0.07)]; SUBJECT_ENDS_QUESTION(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.3.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 04:52:12 -0000 On Mon, Feb 11, 2019 at 9:34 AM John Baldwin wrote: > On 2/10/19 1:13 AM, Jason Harmening wrote: > > I have this review I need to rebase and write the manpage bits for. While > it still ties the the size to the tag, it mostly hides the individual tag: > > https://reviews.freebsd.org/D5704 I like that. It doesn't fix my idealogical gripe about maxsize being a constraint vs. an allocation specifier. But I'm not sure that matters if it can get rid of most/all of the practical ramifications of the problem. Plus it kills off a bunch of other cruft too. Suggestion, maybe dumb: What if you added a flex array of segments at the end of struct bus_dmamem and a maxsegs argument in the args struct to allow multi-seg allocations? That would fix what might be the only real impediment to using this pretty much anywhere. > > > -- > John Baldwin > > > > From owner-freebsd-arch@freebsd.org Tue Feb 12 07:19:40 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1546414D98DC for ; Tue, 12 Feb 2019 07:19:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 72FF975951 for ; Tue, 12 Feb 2019 07:19:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 3178814D98DB; Tue, 12 Feb 2019 07:19:39 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1F0B114D98DA for ; Tue, 12 Feb 2019 07:19:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F3567594F; Tue, 12 Feb 2019 07:19:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1C7JUNF075089 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Feb 2019 09:19:33 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1C7JUNF075089 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1C7JUTB075088; Tue, 12 Feb 2019 09:19:30 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Feb 2019 09:19:30 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: "freebsd-arch@freebsd.org" Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <20190212071929.GB24863@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 07:19:40 -0000 On Mon, Feb 11, 2019 at 04:52:00PM -0800, Conrad Meyer wrote: > Hello, > > The nominal return type of the VOP_INACTIVE vnode method is 'int', but > in practice any error returned is silently discarded. > > The only caller is vinactive(), which is also a void routine. > vinactive ignores the return value of VOP_INACTIVE(). (vinactive > tends to be called by other void routines, like vput(), so propagating > an error up the stack is non-trivial.) > > In practice, most filesystems in the kernel unconditionally return > zero for INACTIVE. The exceptions are: msdosfs, ext2fs, nandfs, and > (notably) ufs. > > The problem (as I see it) is that the return type makes it appear that > INACTIVE is allowed to fail, but it is not. One important > ramification of this is that interruptible sleeps in INACTIVE are > basically not permitted. > > This seems problematic because INACTIVE is invoked as part of > close(2), and we can potentially block that user process indefinitely > when the kernel filesystem is stalled on a network resource, or > something like a FUSE userspace filesystem (which can also access > network resources). > > Can we live with the current behavior (INACTIVE cannot fail)? In that > case, I think we should change its return type to void to match. > > Thoughts? Our close(2) always removes the file descriptor from the process table, regardless of the error returned, except for the EBADF situation. Due to this, if some filesystem like FUSE have to stop executing its VOP_INACTIVE due to signal, it does not change anything for the caller. On the other hand, allowing unbound interruptible sleeps in the implementation of inactive or reclaim is very dangerous practice, since executing the VOPs on the vnode reclamation from VFS daemons would stop free vnode supply to the system, effectively blocking it. In less dangerous situation, it would block unmount. I do not think that efforts to change VOP_INACTIVE() return type to void are worth the time. From owner-freebsd-arch@freebsd.org Tue Feb 12 07:22:29 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C33A914D9ADE for ; Tue, 12 Feb 2019 07:22:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) 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 351A275C98 for ; Tue, 12 Feb 2019 07:22:29 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: by mailman.ysv.freebsd.org (Postfix) id E806814D9ADD; Tue, 12 Feb 2019 07:22:28 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D531014D9ADC for ; Tue, 12 Feb 2019 07:22:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 6B42575C91; Tue, 12 Feb 2019 07:22:28 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) by phk.freebsd.dk (Postfix) with ESMTP id 01A982025652; Tue, 12 Feb 2019 07:22:26 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.15.2/8.15.2) with ESMTPS id x1C7MQjI086318 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 Feb 2019 07:22:26 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.15.2/8.15.2/Submit) id x1C7MQ6N086317; Tue, 12 Feb 2019 07:22:26 GMT (envelope-from phk) To: cem@freebsd.org cc: "freebsd-arch@freebsd.org" Subject: Re: RFC: What to do about VOP_INACTIVE? In-reply-to: From: "Poul-Henning Kamp" References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86315.1549956146.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Tue, 12 Feb 2019 07:22:26 +0000 Message-ID: <86316.1549956146@critter.freebsd.dk> X-Rspamd-Queue-Id: 6B42575C91 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.976,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 07:22:29 -0000 -------- In message , Conrad Meyer writes: >The nominal return type of the VOP_INACTIVE vnode method is 'int', but >in practice any error returned is silently discarded. The return type is an historical accident from John Heidemann's phd. The way he implemented stackable filesystems cast all VOP's to: typedef int vop_t __P((void *)); So that filesystems could have a VOP methodvector which looked like: static struct vnodeopv_entry_desc fifo_vnodeop_entries[] =3D { { &vop_default_desc, (vop_t *) vn_default_error }, { &vop_abortop_desc, (vop_t *) fifo_badop }, { &vop_access_desc, (vop_t *) fifo_ebadf }, { &vop_advlock_desc, (vop_t *) fifo_advlock }, [...] Then on runtime, he built the real vop dispatch tables. Around 1997 I untangled that so that we got compiler type-checks all the way though the VOP calls, and there were enough historical cruft to clean up that I never got around to the return type of the individual VOPs. If you want to fix this, the right thing to do is to add return types in vnode_if.src and teach the tools/vnode_if.awk script about them. -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-arch@freebsd.org Thu Feb 14 17:00:06 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C2E214DA65E for ; Thu, 14 Feb 2019 17:00:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) 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 9CBAA81E24 for ; Thu, 14 Feb 2019 17:00:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5D3E914DA65C; Thu, 14 Feb 2019 17:00:05 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3A98C14DA65A for ; Thu, 14 Feb 2019 17:00:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1ABE81E21 for ; Thu, 14 Feb 2019 17:00:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id n32so7585423qte.11 for ; Thu, 14 Feb 2019 09:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=PrVtpbX/0rmo41QbnfOn+wCdLGXSyEETntpPZYe5QlU=; b=1yhlqSj4IjY85L/mwJ6NZFc0e4V2z89RU3dLo0aI2IjsxjDioxUlVa4zy5dna5VDjh 4OIIolkdMF6TvAUEH7U6rsGIVm1+ZBidcV/la9QAUIlgaqIaPZ4BK6Et1beBgHwmud7S S9xjJNhDPKVZ41w2S1RCJUmw+/shc+IFq3PgqTbtYECOZYpMNw3kaXMwrRlYosXPYaX0 jDKj2Dz5GQgLPvRfEssBwu5ufa5DQLSAezBUIRVsdvUkmtLqwDeg1K9M6d/wXMg1rPEN aHEA19oVhII1gNBJyWyd8EQeZfJH2dlq+F84n8aaxbgX4PhqIZ8hCq3cIRYpPXoYutTH 4e0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PrVtpbX/0rmo41QbnfOn+wCdLGXSyEETntpPZYe5QlU=; b=HG0ecsWY5i/pHQ0xUndSBrlWUG/LhwYfNnpQrPpnHDIYCPoLWu+t2HlKf9+rlzWE7/ 0GT7/lQhqr5AirHrlLtHuzID1kHxFd0l6FBO/79wgI+BCjQZNeLsP5tgn6HQMl1rPCiM UEWmSgV+5PytZo+lDZ/d783Me7sNdpOw/68PDfzEKCq3zhjbEoHLaLV72ij3SIT8y/2Y H+IsEWZDXaF/o8JPgqc5w6mX+fOu1LiFKjN3PGgmfKBHAUJ3AcB7X/w8f4N917n65/pY TkICRJXAuP2BE9qOdsxcckvZKudwIUDX2z/ECR10eoqI6Uy5MYZf/KEAZ4UABjHyVza7 wVUw== X-Gm-Message-State: AHQUAubzssNxRuHL6GvUP87o2kPpL0g0K43YrC+QYn15RHkpifogBNFJ /TY7SnNhPn4VFV3DkQ5QloiYGqmuPBsCUhsd8y3lJA== X-Google-Smtp-Source: AHgI3Ia1bi13EQC7P6aKlFfcODgg5pTszGbf0DWETRl2a0CCHWQ/JpuaZXP+hUmjOLWK3Z2yQA+oLvPCNeOlnKEMP1M= X-Received: by 2002:ac8:16d0:: with SMTP id y16mr3782444qtk.345.1550163603056; Thu, 14 Feb 2019 09:00:03 -0800 (PST) MIME-Version: 1.0 From: Warner Losh Date: Thu, 14 Feb 2019 09:59:52 -0700 Message-ID: Subject: DRM removal soon To: FreeBSD X11 mailing list , "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: F1ABE81E21 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=1yhlqSj4 X-Spamd-Result: default: False [-5.53 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_SHORT(-0.92)[-0.919,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.60)[ip: (-8.41), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-1.98), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:00:06 -0000 The parts of drm that we're removing are up for review: https://reviews.freebsd.org/D19196 Since the drm-legacy-kmod or the drm-kmod packages seem to be stable and working well for most people, the time has come to finish the removal of most of the drm code in FreeBSD. The intel and radeon drivers will be removed. The ability to build things as a module will be removed. Some bits will remain for the TEGRA arm board, since the transition from the drm code base isn't as straight forward as it was for the intel and amd drivers (the effort to emulate the kernel environment on arm is significantly higher than x86 because in addition to programming to the GPU, clocks, power regulators, etc need to be programmed as well. The interfaces here are not standardized and different greatly between FreeBSD and Linux). Absent any significant last minute issue, it is my intention to commit this change on Feb 21st, which is 20 days later than had been previously announced. Warner From owner-freebsd-arch@freebsd.org Thu Feb 14 17:51:14 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB31714DBC1E for ; Thu, 14 Feb 2019 17:51:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) 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 40E5883D2F for ; Thu, 14 Feb 2019 17:51:14 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id F26DB14DBC1D; Thu, 14 Feb 2019 17:51:13 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B27FD14DBC1C for ; Thu, 14 Feb 2019 17:51:13 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-it1-f169.google.com (mail-it1-f169.google.com [209.85.166.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AAC2083D28 for ; Thu, 14 Feb 2019 17:51:12 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-it1-f169.google.com with SMTP id z9so15299840itc.4 for ; Thu, 14 Feb 2019 09:51:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=JyLb04kHvZvjdqzezoH3NL6czs51H+m04qlPpWoc8Tk=; b=aMcEarQEtu3CRFJQaH1duwWwp830SSWqfPgdOQDKmj398XYl5lezm3KymIQCt51qbA OHgZhpf/Kg5oO01SAQnVOWCERrjrdAYEG7BbiI0lB7od89YBuErAE7L8Pgun453tNBs4 IP7ymuPlDXdefPMCw529Suk/QfA2WOUzosEoWpv/CpQ9ShAv0bg59akWfxen8REuVCcf SBLRSn4kVsrBdKl1ZHUK32pAV8nXKWeQWYp+znjuNsZsPMdIdH23ksEJ2l7yHAy+r1Uf pNwJafv0byOKcs5u4k+b9Rf9cwn8BxFDShC2GFwTrvKz1TcoNpF874e5vIRiQPrM5oLo XHXQ== X-Gm-Message-State: AHQUAuaeG9n1y1Ls28IU9/W3oBAbTxFJ3w+siLIv5e0L0/rQC9WNQVw8 7LVJafqO6QE54gvs8ZYhQzbRNILk X-Google-Smtp-Source: AHgI3IZEu5G7sY214o186w4MxLkJytZQa+NOSFfEcdXxXmiqXGeipJ46IkFOGoB4dOuDFzwha39iLg== X-Received: by 2002:a6b:c402:: with SMTP id y2mr3317795ioa.77.1550166666159; Thu, 14 Feb 2019 09:51:06 -0800 (PST) Received: from mail-it1-f170.google.com (mail-it1-f170.google.com. [209.85.166.170]) by smtp.gmail.com with ESMTPSA id n16sm1182220iom.58.2019.02.14.09.51.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 09:51:06 -0800 (PST) Received: by mail-it1-f170.google.com with SMTP id l66so6339568itg.3 for ; Thu, 14 Feb 2019 09:51:05 -0800 (PST) X-Received: by 2002:a02:9f86:: with SMTP id a6mr2739915jam.87.1550166665828; Thu, 14 Feb 2019 09:51:05 -0800 (PST) MIME-Version: 1.0 References: <20190212071929.GB24863@kib.kiev.ua> In-Reply-To: <20190212071929.GB24863@kib.kiev.ua> Reply-To: cem@freebsd.org From: Conrad Meyer Date: Thu, 14 Feb 2019 09:50:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: What to do about VOP_INACTIVE? To: Konstantin Belousov Cc: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: AAC2083D28 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.166.169 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [-4.79 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[cem@freebsd.org]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.82)[-0.824,0]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[arch@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[169.166.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[169.166.85.209.rep.mailspike.net : 127.0.0.17]; IP_SCORE(-2.96)[ip: (-8.95), ipnet: 209.85.128.0/17(-3.77), asn: 15169(-1.98), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 17:51:15 -0000 Hi Konstantin, On Mon, Feb 11, 2019 at 11:19 PM Konstantin Belousov wrote: > Our close(2) always removes the file descriptor from the process table, > regardless of the error returned, except for the EBADF situation. > Due to this, if some filesystem like FUSE have to stop executing its > VOP_INACTIVE due to signal, it does not change anything for the caller. Sure. Does it violate any contract that the kernel relies upon? For example, vgonel() will issue a VOP_INACTIVE() followed by VOP_RECLAIM(); I guess this means filesystems with interruptible INACTIVE cannot rely upon RECLAIMed vnodes being inactivated first. > On the other hand, allowing unbound interruptible sleeps in the > implementation of inactive or reclaim is very dangerous practice, since > executing the VOPs on the vnode reclamation from VFS daemons would stop > free vnode supply to the system, effectively blocking it. In less > dangerous situation, it would block unmount. This is a good concern. Even bounding sleep to some plausible time per individual vnode would drastically restrict VFS daemons' ability to process many vnodes in a timely fashion. And eliminating sleeps or bounding them to very short times may be undesirable the majority of the time (userspace close). I don't know what the best way to fix this is. We could plumb a flag argument down to INACTIVE and RECLAIM methods. On the other hand, we already have the 'td' argument. Maybe that is a sufficient for VOP methods to determine whether the caller is userspace or a kernel daemon. Either way, vinactive() and callers will not make any use of an EAGAIN signal, so why have the 'int' return type? It is misleading. > I do not think that efforts to change VOP_INACTIVE() return type to void > are worth the time. It's trivial; I'm happy to do it. Thanks, Conrad From owner-freebsd-arch@freebsd.org Thu Feb 14 18:01:05 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF5BD14DC190 for ; Thu, 14 Feb 2019 18:01:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A8F7384329 for ; Thu, 14 Feb 2019 18:01:04 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1EI12a8067829 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 10:01:02 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1EI11xl067828; Thu, 14 Feb 2019 10:01:01 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2019 10:01:01 -0800 From: Steve Kargl To: imp@bsdimp.com, freebsd-arch@freebsd.org Subject: "DRM removal soon" is premature Message-ID: <20190214180101.GB67712@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: A8F7384329 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.20 / 15.00]; ARC_NA(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.73)[0.726,0]; IP_SCORE(0.09)[ip: (0.18), ipnet: 128.95.0.0/16(0.25), asn: 73(0.11), country: US(-0.07)]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; NEURAL_HAM_LONG(-0.32)[-0.319,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.01)[0.006,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:01:05 -0000 Warner, I'm not subscribed to freebsd-arch (well I am now!) drm-legacy-kmod is broken on i386-*-freebsd due to r343567. I posted about this issue in freebsd-current, freebsd-x11 lists. Find yourself a post r343567 system, build drm-legacy-kmod, and xorg and see what happens. https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html -- Steve From owner-freebsd-arch@freebsd.org Thu Feb 14 18:08:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9CBAF14DC40A for ; Thu, 14 Feb 2019 18:08:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0667849EA for ; Thu, 14 Feb 2019 18:08:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82c.google.com with SMTP id v10so7905897qtp.8 for ; Thu, 14 Feb 2019 10:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xFYCIi8ja5bo/v+pmfQz5DgX83SN6QsIHOcjsk6dX7E=; b=n3TXOoHlKnH62jD2tsF67ddZ+1/ktznKsXdSeKL2D21axbub6nLIIIcAP/q8oD5hUL AgZnMJJlux18JAyORBUK1fXqR69gNMCbLqbJrG4htnEOh3Rz1btg9GJSqkUT+2cbqHHj bi01uiq87HxJLLpr1FmgQ5J5zJ3ABq7Om0YhI/zBVp0P1ngVk1bxX9uM7IASPrrPK+Hh ajVq5Oer9sgpbbFmhLZoUGP0JJs6depp631jlPI6HeGN4q4IiWPzl67e11PldIbie6uN 5J44BDNtSOuzD6JD4t5RqYjDx7438BrnZ1/IP11tSveHaS6JP90vnt3sjUo6aaF725BR NDdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xFYCIi8ja5bo/v+pmfQz5DgX83SN6QsIHOcjsk6dX7E=; b=JOn4RsMcHXIX62RJEShmFV/x2blIw47uynIoP6jN8MN4N9Nm9KNm1dwkocjpKUMXAS gCYQ7chIi7zh+vZs8mQ4AmGO9bw10i5tQHt61GnxXeeo9IlWKvQW4CyFO3DrXibZwHTE SQ9z5LsVStqBywu7Ovz0th/ekP/PT2BMkxsG9AMIg+V4r+FwxZ6kB9MD7CPiij0d5tW9 SyXD9tZfE492uezY6DNgjez2BvxBz4UmoK47PdG4f5VlqOurqQJ2je8Na/6XHXqpt5Xs VuCmtD5Z4wNWxoEl/QGZjhqaFflsA9RR1mahuEbmV/S2KZTsNA2bI4cYjJp+lCTHz3mQ HP7g== X-Gm-Message-State: AHQUAua77W41PQvqsoGP7hApkZtoxdZ3ArrNQaZfMFtaw/qxDKAgrrzr nR2O+Rl0bwIG5kuDdKUzlRQpQbNKp7k33suGdSgSwLgO X-Google-Smtp-Source: AHgI3IbJQbffjcbTD/QeIVwS0klIhFhfH/M+cwbtdBMYrrlf3w4kkS6rGsgVdz8MJ6TKEVPIq3F5JjAqP9QZBw6I4JA= X-Received: by 2002:a0c:b68a:: with SMTP id u10mr4013922qvd.57.1550167710112; Thu, 14 Feb 2019 10:08:30 -0800 (PST) MIME-Version: 1.0 References: <20190214180101.GB67712@troutmask.apl.washington.edu> In-Reply-To: <20190214180101.GB67712@troutmask.apl.washington.edu> From: Warner Losh Date: Thu, 14 Feb 2019 11:08:18 -0700 Message-ID: Subject: Re: "DRM removal soon" is premature To: Steve Kargl Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: B0667849EA X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=n3TXOoHl X-Spamd-Result: default: False [-5.55 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_SHORT(-0.85)[-0.850,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[c.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.69)[ip: (-8.82), ipnet: 2607:f8b0::/32(-2.55), asn: 15169(-1.98), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:08:31 -0000 On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > Warner, > > I'm not subscribed to freebsd-arch (well I am now!) > > drm-legacy-kmod is broken on i386-*-freebsd due > to r343567. I posted about this issue in > freebsd-current, freebsd-x11 lists. Find yourself > a post r343567 system, build drm-legacy-kmod, and > xorg and see what happens. > > > https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html The in-tree versions don't even compile, how are they better than the drm-legacy-kmod modules which do, but don't work for some people (and do for others)? Warner From owner-freebsd-arch@freebsd.org Thu Feb 14 18:24:24 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58ECB14DCEE8 for ; Thu, 14 Feb 2019 18:24:24 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A81EF856EC for ; Thu, 14 Feb 2019 18:24:21 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1EIOJSv068006 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 10:24:19 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1EIOJFR068005; Thu, 14 Feb 2019 10:24:19 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2019 10:24:19 -0800 From: Steve Kargl To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature Message-ID: <20190214182419.GA67872@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: A81EF856EC X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.67)[0.668,0]; NEURAL_HAM_LONG(-0.44)[-0.436,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.30)[0.304,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.09)[ip: (0.18), ipnet: 128.95.0.0/16(0.25), asn: 73(0.11), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:24:24 -0000 On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > Warner, > > > > I'm not subscribed to freebsd-arch (well I am now!) > > > > drm-legacy-kmod is broken on i386-*-freebsd due > > to r343567. I posted about this issue in > > freebsd-current, freebsd-x11 lists. Find yourself > > a post r343567 system, build drm-legacy-kmod, and > > xorg and see what happens. > > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html > > > The in-tree versions don't even compile, how are they better than the > drm-legacy-kmod modules which do, but don't work for some people (and do > for others)? > The in-tree version does not compile because someone disconnected drm2 from the build. r342567 would not have happen if drm2 was not disconnected. In your original post (which I cannot respond to as I came too late to freebsd-arch), you wrote Since the drm-legacy-kmod or the drm-kmod packages seem to be stable and working well for most people, the time has come to finish the removal of most of the drm code in FreeBSD. I'm pointing out the fallacy of that statement for anyone running freebsd-current on i386 who uses drm-legacy-kmod. Niclas proposed a fixed for drm-legacy-kmod here https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022759.html I reported on testing his proposed fix here https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022760.html and here https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022762.html -- Steve From owner-freebsd-arch@freebsd.org Thu Feb 14 18:30:10 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A025B14DD2BE for ; Thu, 14 Feb 2019 18:30:10 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from mail.daemonic.se (mail.daemonic.se [IPv6:2607:f740:d:20::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0256A85C0D for ; Thu, 14 Feb 2019 18:30:10 +0000 (UTC) (envelope-from zeising@freebsd.org) Received: from cid.daemonic.se (localhost [IPv6:::1]) by mail.daemonic.se (Postfix) with ESMTP id 440lLR3h0czDjCL; Thu, 14 Feb 2019 18:30:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at daemonic.se Received: from mail.daemonic.se ([127.0.0.1]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256) by cid.daemonic.se (mailscanner.daemonic.se [127.0.0.1]) (amavisd-new, port 10587) with ESMTPS id HUjjtGSnyQMR; Thu, 14 Feb 2019 18:30:06 +0000 (UTC) Received: from vivi.daemonic.se (vivi.daemonic.se [IPv6:2001:470:dca9:2::4]) by mail.daemonic.se (Postfix) with ESMTPSA id 440lLC75nNzDjVS; Thu, 14 Feb 2019 18:29:55 +0000 (UTC) Subject: Re: "DRM removal soon" is premature To: Warner Losh , Steve Kargl Cc: "freebsd-arch@freebsd.org" References: <20190214180101.GB67712@troutmask.apl.washington.edu> From: Niclas Zeising Message-ID: Date: Thu, 14 Feb 2019 19:29:47 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 0256A85C0D X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.98)[-0.980,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; ASN(0.00)[asn:36236, ipnet:2607:f740:d::/48, country:US] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:30:10 -0000 On 2/14/19 7:08 PM, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > >> Warner, >> >> I'm not subscribed to freebsd-arch (well I am now!) >> >> drm-legacy-kmod is broken on i386-*-freebsd due >> to r343567. I posted about this issue in >> freebsd-current, freebsd-x11 lists. Find yourself >> a post r343567 system, build drm-legacy-kmod, and >> xorg and see what happens. >> >> >> https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html >> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html > > > The in-tree versions don't even compile, how are they better than the > drm-legacy-kmod modules which do, but don't work for some people (and do > for others)? > The code in drm-legacy-kmod and in base is exactly the same, with two exceptions. The port uses gpu-firmware-kmod instead of the base firmware, so paths has been adjsusted, and there is a fix in there to make it compile on 13, something that's not even in the base code. I can give you a patch to the base stuff to make it compile (based on the one in drm-legacy-kmod) if you are interested in testing, but I'm pretty sure the failure will be the same, in your set up. Regards -- Niclas Zeising FreeBSD Graphics Team From owner-freebsd-arch@freebsd.org Thu Feb 14 18:35:35 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8534914DD57F for ; Thu, 14 Feb 2019 18:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 08D1086002 for ; Thu, 14 Feb 2019 18:35:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BB7A114DD57E; Thu, 14 Feb 2019 18:35:34 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 965BA14DD57D for ; Thu, 14 Feb 2019 18:35:34 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DE9FF86000; Thu, 14 Feb 2019 18:35:33 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id x1EIZPaM011795 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 20:35:28 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x1EIZPaM011795 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x1EIZPbX011793; Thu, 14 Feb 2019 20:35:25 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Feb 2019 20:35:25 +0200 From: Konstantin Belousov To: Conrad Meyer Cc: "freebsd-arch@freebsd.org" Subject: Re: RFC: What to do about VOP_INACTIVE? Message-ID: <20190214183525.GK24863@kib.kiev.ua> References: <20190212071929.GB24863@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:35:35 -0000 On Thu, Feb 14, 2019 at 09:50:55AM -0800, Conrad Meyer wrote: > Hi Konstantin, > > On Mon, Feb 11, 2019 at 11:19 PM Konstantin Belousov > wrote: > > Our close(2) always removes the file descriptor from the process table, > > regardless of the error returned, except for the EBADF situation. > > Due to this, if some filesystem like FUSE have to stop executing its > > VOP_INACTIVE due to signal, it does not change anything for the caller. > > Sure. Does it violate any contract that the kernel relies upon? For > example, vgonel() will issue a VOP_INACTIVE() followed by > VOP_RECLAIM(); I guess this means filesystems with interruptible > INACTIVE cannot rely upon RECLAIMed vnodes being inactivated first. VFS does not guarantee that VOP_INACTIVE is always called when the use count reaches zero. Look e.g. at vputx() where we only call the inactive method when we were able to upgrade to exclusive lock, and look at vget() where we only call it when we locked exclusive. In other words, the reclaim method of a filesystem must be prepared to do the work, it is typically done by calling internal inactivation function from VOP_RECLAIM. > > > On the other hand, allowing unbound interruptible sleeps in the > > implementation of inactive or reclaim is very dangerous practice, since > > executing the VOPs on the vnode reclamation from VFS daemons would stop > > free vnode supply to the system, effectively blocking it. In less > > dangerous situation, it would block unmount. > > This is a good concern. Even bounding sleep to some plausible time > per individual vnode would drastically restrict VFS daemons' ability > to process many vnodes in a timely fashion. And eliminating sleeps or > bounding them to very short times may be undesirable the majority of > the time (userspace close). > > I don't know what the best way to fix this is. We could plumb a flag > argument down to INACTIVE and RECLAIM methods. On the other hand, we > already have the 'td' argument. Maybe that is a sufficient for VOP > methods to determine whether the caller is userspace or a kernel > daemon. > > Either way, vinactive() and callers will not make any use of an EAGAIN > signal, so why have the 'int' return type? It is misleading. > > > I do not think that efforts to change VOP_INACTIVE() return type to void > > are worth the time. > > It's trivial; I'm happy to do it. > > Thanks, > Conrad From owner-freebsd-arch@freebsd.org Thu Feb 14 18:51:53 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFBE214DDBEB for ; Thu, 14 Feb 2019 18:51:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFD4A86871 for ; Thu, 14 Feb 2019 18:51:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x829.google.com with SMTP id 2so8081917qtb.5 for ; Thu, 14 Feb 2019 10:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CIICDHJj2nsda9h70leVJRhHoWt/tcHjNU71q86KFC0=; b=lXLOWJ70IePbeLV6sonkTjos/Ax8zOT3Vz14pMmqawV2Q8ItgbSFN7J2SxBLjtrry9 +mZNtJXjPJQ800kW5QpNCIiHbyE8YPKbZDJk7PtL5w0Adpl078PN94d1Kh7JIrWTLy9X XIlzv6PhhJgcGl/Ka2lPX/eLH1lR8Zti/aSPM7m1ymwbsvQxHR6fR3NjDAJGRWYadhcf PrRTyM0zJ1Q+8Fl6u3LqRRV0bgNEwwLcc0/rE4Bga+xJ3TKIcVhRzauOkXUr+ghbWaO3 vLitRoLlOmwrlY6A7lSwZ/6B+1rQx0Iii//MeeYMECwaKxR6Gpel4QCewafbn1PHP1Gq fGZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CIICDHJj2nsda9h70leVJRhHoWt/tcHjNU71q86KFC0=; b=DUJ00qqpcQnGNG0PPaznhRiB/9xI9PWGqK3JxImEhvjr2275rBRNnpV8ZjLxo3TmFH T6AAcZDvelx/WEUX4gIV3EAwi3SU43BnVNOgmXg6j2N64PYkShJc6mxV5nnI/ruDlRe2 jH7+BfSqfVKJefOZzam+RMk4S9+dy63afjbmD+EhO4n9UpfeK9iWGhytYU1q+cTGISJ2 ZcX5TFL1SZ8cxmwa80dpuMcH9kDsUmXDbq4q0Whi53LUTbpuww3oal0Y0aBRSIlhg6MC Lw/t/BcR5CTqSNFDsDfpk6RULexSl58I9BoxslBsfREtNziznQzwCTDzt5s8IjhCm0rH OQBw== X-Gm-Message-State: AHQUAuYc184jelnr7lmjVvfj9evuqCuhAakO5OFZzoTc8K576YLHHutZ O2thpuRirSJXIayepn0xIJi+hkOkUN/yfeSeLRbafc4R5Vk= X-Google-Smtp-Source: AHgI3Ib5pBQvmkytLD7sFSAopvStmF3iBzjyUP/mSMp9DE1FegfE6Qib4dRBS88bPUErTkbk5MDghsG9eAKoYLhxuEM= X-Received: by 2002:a0c:b068:: with SMTP id l37mr4275028qvc.21.1550170312024; Thu, 14 Feb 2019 10:51:52 -0800 (PST) MIME-Version: 1.0 References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> In-Reply-To: <20190214182419.GA67872@troutmask.apl.washington.edu> From: Warner Losh Date: Thu, 14 Feb 2019 11:51:41 -0700 Message-ID: Subject: Re: "DRM removal soon" is premature To: Steve Kargl Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: AFD4A86871 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=lXLOWJ70 X-Spamd-Result: default: False [-5.59 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_SHORT(-0.80)[-0.795,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[9.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.78)[ip: (-9.31), ipnet: 2607:f8b0::/32(-2.56), asn: 15169(-1.98), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 18:51:53 -0000 On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote: > > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > Warner, > > > > > > I'm not subscribed to freebsd-arch (well I am now!) > > > > > > drm-legacy-kmod is broken on i386-*-freebsd due > > > to r343567. I posted about this issue in > > > freebsd-current, freebsd-x11 lists. Find yourself > > > a post r343567 system, build drm-legacy-kmod, and > > > xorg and see what happens. > > > > > > > > > > https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html > > > > > > The in-tree versions don't even compile, how are they better than the > > drm-legacy-kmod modules which do, but don't work for some people (and do > > for others)? > > > > The in-tree version does not compile because someone disconnected > drm2 from the build. r342567 would not have happen if drm2 was > not disconnected. Technically, it's just off by default. It's still connected to the build. We just don't have a good way to lint the code, as drm isn't in i386 NOTES. > In your original post (which I cannot respond > to as I came too late to freebsd-arch), you wrote > > Since the drm-legacy-kmod or the drm-kmod packages seem to be > stable and working well for most people, the time has come to > finish the removal of most of the drm code in FreeBSD. > > I'm pointing out the fallacy of that statement for anyone > running freebsd-current on i386 who uses drm-legacy-kmod. > Hence my qualification of "most people" :) > Niclas proposed a fixed for drm-legacy-kmod here > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022759.html > > I reported on testing his proposed fix here > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022760.html > > and here > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022762.html You might try this fix instead, though I don't think it will matter. I think the breakage you're seeing is a result of a subtle dependency in the drm2/ttm code with FreeBSD's vm system. Even had it been connected to the build and fixed at the time, I don't think it would have mattered. diff --git a/sys/dev/drm2/ttm/ttm_bo.c b/sys/dev/drm2/ttm/ttm_bo.c index 010afe6d8b3b..20083ff0fb53 100644 --- a/sys/dev/drm2/ttm/ttm_bo.c +++ b/sys/dev/drm2/ttm/ttm_bo.c @@ -1498,11 +1498,11 @@ int ttm_bo_global_init(struct drm_global_reference *ref) tries = 0; retry: glob->dummy_read_page = vm_page_alloc_contig(NULL, 0, req, - 1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); + 1, 0, 0xfffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); if (unlikely(glob->dummy_read_page == NULL)) { if (tries < 1 && vm_page_reclaim_contig(req, 1, - 0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { + 0, 0xfffffffful, PAGE_SIZE, 0)) { tries++; goto retry; } Since that will eliminate the possibility that PAE is defined and giving a bigger max. Though it also likely won't matter if you have < 4GB of RAM in your machine. Obviously, this patch is not committable, but if it works it tells us something. But as I said, I doubt this will work as there's something subtle (likely the size of a variable or struct element) in ttm that's now out of sync. Warner From owner-freebsd-arch@freebsd.org Thu Feb 14 19:02:49 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0F1114DDFEB for ; Thu, 14 Feb 2019 19:02:48 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 72EA486FAC for ; Thu, 14 Feb 2019 19:02:47 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1EJ2ieb068366 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 11:02:44 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1EJ2ixb068365; Thu, 14 Feb 2019 11:02:44 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2019 11:02:44 -0800 From: Steve Kargl To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature Message-ID: <20190214190244.GA68143@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 72EA486FAC X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.46 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.76)[0.759,0]; NEURAL_HAM_LONG(-0.42)[-0.420,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.33)[0.335,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.09)[ip: (0.18), ipnet: 128.95.0.0/16(0.24), asn: 73(0.11), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:02:49 -0000 On Thu, Feb 14, 2019 at 11:51:41AM -0700, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: > > > On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote: > > > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < > > > In your original post (which I cannot respond > > to as I came too late to freebsd-arch), you wrote > > > > Since the drm-legacy-kmod or the drm-kmod packages seem to be > > stable and working well for most people, the time has come to > > finish the removal of most of the drm code in FreeBSD. > > > > I'm pointing out the fallacy of that statement for anyone > > running freebsd-current on i386 who uses drm-legacy-kmod. > > > > Hence my qualification of "most people" :) > > > Niclas proposed a fixed for drm-legacy-kmod here > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022759.html > > > > I reported on testing his proposed fix here > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022760.html > > > > and here > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022762.html > > You might try this fix instead, though I don't think it will matter. I > think the breakage you're seeing is a result of a subtle dependency in the > drm2/ttm code with FreeBSD's vm system. Even had it been connected to the > build and fixed at the time, I don't think it would have mattered. > I can't test the patch for several hours, and it will take 6 to 7 hours to rebuild world/kernel. So, I'll have to report back tomorrow. -- Steve From owner-freebsd-arch@freebsd.org Thu Feb 14 19:04:59 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E8DC14DE082 for ; Thu, 14 Feb 2019 19:04:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 013518708A for ; Thu, 14 Feb 2019 19:04:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id i5so4221027qkd.13 for ; Thu, 14 Feb 2019 11:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wkaeynv4MuAx1wC/JdaidxzfUw/0Nlxh0fYGbUUsJM0=; b=AM0fvsMZH7WuW8BTuWl1aGwcshHFkC0yptAFoTq9HlUTEd0K49FzKvT+P43wQU/ezh Clq5zWIuO3f4DMMEQ2JRuT5Y5NaTsQtiFRkmC2YF1QPwECc1bcVhhrsbZz1K67O1aU+g wXutUymwLCC8dkUSAmfn6ISCswfzeMAqTKpB78syleLoMNMjLeCT2fhTTrJxz2F4xbYG TaI9l2jsKqxtfJ4BItxXHT+G2xnXuO+pAwgOwUQckfAxA9Y8i1n6dTsy9f5976LDIw/6 CeTvWW7faGMuQlvZ3i4UEzdiWy5kIiWn0KV7GDKZna2oT4YQAJ2XenoW3wMlfc+rYpLT v3LA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wkaeynv4MuAx1wC/JdaidxzfUw/0Nlxh0fYGbUUsJM0=; b=uT4UTZgjw0mgF4NCjs3Jr9D67bSTcmToxLN9Eh4N45CayAA/Hw303cqwgSD6UD00p3 VG4HNKht5VR8Yx/o/ZgdTYUQ8iRvvlrdwpXCbNDsISxNatUfAkARD3/7uTNAtUI5id8Y +LcDSZ1jS000SYqynLNUJbRmDyNkFKFM1xeTpL6tToS2BHbsgq1I332VwCtCE0b6HPJP GC11dpxTR7SoiJ726rmIf2zHR1ruRw1O6Pu2p0sZc0kVU/B8PN8oe94k5YrctPS/ynuj /LgTxEfxdRx6G0wLA51vtUrBaEWx/jG2h8Jn4zNx4YAzeh557YlXtKRAFOF6yO+iSg5u lccA== X-Gm-Message-State: AHQUAubsrC3Sx4//mxIg4wO3M2h1lYinp+Qxhzpv2z0V6r8M/DeKVfdr ixEmvaAjXasU0voCMipqf+iKNy9MlqjjBPTSnp7VrZSL X-Google-Smtp-Source: AHgI3IZ8MGLTTOCt+Oz3ZNOSE14WXQOLfbQTPHERtNj8rzQVS/e031QcFcbkXpQz2EgP7e85ryMEmm/sKPhZ1qgHUro= X-Received: by 2002:a37:a407:: with SMTP id n7mr1801530qke.46.1550171097476; Thu, 14 Feb 2019 11:04:57 -0800 (PST) MIME-Version: 1.0 References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> In-Reply-To: <20190214190244.GA68143@troutmask.apl.washington.edu> From: Warner Losh Date: Thu, 14 Feb 2019 12:04:46 -0700 Message-ID: Subject: Re: "DRM removal soon" is premature To: Steve Kargl Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 013518708A X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=AM0fvsMZ X-Spamd-Result: default: False [-5.63 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_HAM_SHORT(-0.83)[-0.833,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[a.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.79)[ip: (-9.34), ipnet: 2607:f8b0::/32(-2.56), asn: 15169(-1.98), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:04:59 -0000 On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl < sgk@troutmask.apl.washington.edu> wrote: > On Thu, Feb 14, 2019 at 11:51:41AM -0700, Warner Losh wrote: > > On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < > > sgk@troutmask.apl.washington.edu> wrote: > > > > > On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote: > > > > On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < > > > > > In your original post (which I cannot respond > > > to as I came too late to freebsd-arch), you wrote > > > > > > Since the drm-legacy-kmod or the drm-kmod packages seem to be > > > stable and working well for most people, the time has come to > > > finish the removal of most of the drm code in FreeBSD. > > > > > > I'm pointing out the fallacy of that statement for anyone > > > running freebsd-current on i386 who uses drm-legacy-kmod. > > > > > > > Hence my qualification of "most people" :) > > > > > Niclas proposed a fixed for drm-legacy-kmod here > > > > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022759.html > > > > > > I reported on testing his proposed fix here > > > > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022760.html > > > > > > and here > > > > > > > https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022762.html > > > > You might try this fix instead, though I don't think it will matter. I > > think the breakage you're seeing is a result of a subtle dependency in > the > > drm2/ttm code with FreeBSD's vm system. Even had it been connected to the > > build and fixed at the time, I don't think it would have mattered. > > > > I can't test the patch for several hours, and it will take > 6 to 7 hours to rebuild world/kernel. So, I'll have to report > back tomorrow. > You'd only need to rebuild sys/modules/drm2, since that's the only thing that will change with the patch. But I can wait. I won't be removing things before tomorrow. Warner From owner-freebsd-arch@freebsd.org Thu Feb 14 19:17:44 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26A2114DE5C3 for ; Thu, 14 Feb 2019 19:17:44 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 164E88797D for ; Thu, 14 Feb 2019 19:17:42 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1EJHdM5069103 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 11:17:39 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1EJHdGT069102; Thu, 14 Feb 2019 11:17:39 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2019 11:17:39 -0800 From: Steve Kargl To: Warner Losh Cc: "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature Message-ID: <20190214191739.GA68371@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 164E88797D X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.50 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.88)[0.875,0]; NEURAL_HAM_LONG(-0.47)[-0.471,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.31)[0.315,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.09)[ip: (0.18), ipnet: 128.95.0.0/16(0.24), asn: 73(0.10), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:17:44 -0000 On Thu, Feb 14, 2019 at 12:04:46PM -0700, Warner Losh wrote: > On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl < > > > > I can't test the patch for several hours, and it will take > > 6 to 7 hours to rebuild world/kernel. So, I'll have to report > > back tomorrow. > > > > You'd only need to rebuild sys/modules/drm2, since that's the only thing > that will change with the patch. > > But I can wait. I won't be removing things before tomorrow. > Well, to get the laptop functional again, so that I could continue testing some libm changes, I reverted trunk back to r343566. I would need to pull in r343567 with the pmap.h changes. Apply your patch to drm2, and rebuild the entire kernel (including WITH_MODULE_DRM2). I don't know if this new kernel would be incompatible with the old world. -- Steve From owner-freebsd-arch@freebsd.org Thu Feb 14 19:59:36 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 413C114DF983 for ; Thu, 14 Feb 2019 19:59:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 5743089199 for ; Thu, 14 Feb 2019 19:59:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id B09D17601D4; Fri, 15 Feb 2019 06:59:22 +1100 (AEDT) Date: Fri, 15 Feb 2019 06:59:21 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Steve Kargl cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature In-Reply-To: <20190214182419.GA67872@troutmask.apl.washington.edu> Message-ID: <20190215063544.F4212@besplex.bde.org> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=P6RKvmIu c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=6I5d2MoRAAAA:8 a=pFcttl64oSGRVS1MgW4A:9 a=CjuIK1q_8ugA:10 a=zECsQ65LB1IA:10 a=htYI6iZgXlIA:10 a=IjZwj45LgO3ly-622nXo:22 X-Rspamd-Queue-Id: 5743089199 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.42 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-6.44 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[42.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-0.87)[-0.871,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-3.25)[ip: (-8.80), ipnet: 211.28.0.0/14(-4.14), asn: 4804(-3.29), country: AU(-0.04)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 19:59:36 -0000 On Thu, 14 Feb 2019, Steve Kargl wrote: > On Thu, Feb 14, 2019 at 11:08:18AM -0700, Warner Losh wrote: >> On Thu, Feb 14, 2019 at 11:01 AM Steve Kargl < >> sgk@troutmask.apl.washington.edu> wrote: >>> ... >>> drm-legacy-kmod is broken on i386-*-freebsd due >>> to r343567. I posted about this issue in >>> freebsd-current, freebsd-x11 lists. Find yourself >>> a post r343567 system, build drm-legacy-kmod, and >>> xorg and see what happens. KBI changes like r343567 indeed give DLL hell. I usually avoid this by not using modules, but recently decided to test drm2, and now have 4 sets of modules for 4 types of kernels (i386-3+1, i386+4+4-post-r343567, i386+4+4-post-r343567-less-1-KBI-change, and amd64). I currently have 86 test kernels going back to FreeBSD-7 and reboot with about the last 10 of them frequently. >>> https://lists.freebsd.org/pipermail/freebsd-current/2019-February/072802.html >>> https://lists.freebsd.org/pipermail/freebsd-x11/2019-February/022754.html >> >> The in-tree versions don't even compile, how are they better than the >> drm-legacy-kmod modules which do, but don't work for some people (and do >> for others)? They do compile, except for 1 macro in 1 radeon (ttm) file broken by r343567. I used a quick fix. They probably still don't compile with gcc, but I used clang. I only needed drm2 for i915kms and don't miss radeon. I built them using a normal build (cd ~/bde/sysXXX/modules/XXX; make, after fixing or working around bugs in .PATH statements). drm2/i915kms almost works. It actually works better after r343567. Before then, it usually hands on unload and panics on reload. > The in-tree version does not compile because someone disconnected > drm2 from the build. r342567 would not have happen if drm2 was > not disconnected. In your original post (which I cannot respond > to as I came too late to freebsd-arch), you wrote drm2 never compiled as a non-module since its files aren't in conf/files. And it never was in LINT, so never was well tested since LINT doesn't contain modules, except possibly under the kernel tree where the build has other problems and never worked for me since it doesn't pass down critical macros (like CC=cc -m32 and my more specialized ones). Bruce From owner-freebsd-arch@freebsd.org Thu Feb 14 20:20:19 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3378314DFFD5 for ; Thu, 14 Feb 2019 20:20:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id BCCB1899AF for ; Thu, 14 Feb 2019 20:20:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 2692343D606; Fri, 15 Feb 2019 07:20:13 +1100 (AEDT) Date: Fri, 15 Feb 2019 07:20:13 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Warner Losh cc: Steve Kargl , "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature In-Reply-To: Message-ID: <20190215065959.S4212@besplex.bde.org> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=WITgNBLsjsO_3sEmIlAA:9 a=9uZw6LUloKBpbY4p:21 a=CfD_xi55dttBI0Az:21 a=CjuIK1q_8ugA:10 X-Rspamd-Queue-Id: BCCB1899AF X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of brde@optusnet.com.au designates 211.29.132.246 as permitted sender) smtp.mailfrom=brde@optusnet.com.au X-Spamd-Result: default: False [-6.16 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.132.29.211.list.dnswl.org : 127.0.5.1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:211.29.132.0/23]; FREEMAIL_FROM(0.00)[optusnet.com.au]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[optusnet.com.au]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: extmail.optusnet.com.au]; NEURAL_HAM_SHORT(-0.86)[-0.862,0]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; IP_SCORE(-2.99)[ip: (-7.44), ipnet: 211.28.0.0/14(-4.15), asn: 4804(-3.30), country: AU(-0.04)]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[optusnet.com.au]; ASN(0.00)[asn:4804, ipnet:211.28.0.0/14, country:AU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 20:20:19 -0000 On Thu, 14 Feb 2019, Warner Losh wrote: > On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < > sgk@troutmask.apl.washington.edu> wrote: >> ... >> The in-tree version does not compile because someone disconnected >> drm2 from the build. r342567 would not have happen if drm2 was >> not disconnected. > > Technically, it's just off by default. It's still connected to the build. > We just don't have a good way to lint the code, as drm isn't in i386 NOTES. It is also only built in the modules tree if MK_MODULES_DRM2 is set (with further convolutions for MACHINE_CPU_ARCH). This is apparently not set set by default or forced for universe, so drm2 doesn't get tested by universe either, and even extensively tests for changes like r343567 don't notice when they break it. > You might try this fix instead, though I don't think it will matter. I > think the breakage you're seeing is a result of a subtle dependency in the > drm2/ttm code with FreeBSD's vm system. Even had it been connected to the > build and fixed at the time, I don't think it would have mattered. Another bug in the module is that it has no man pages. I used kldload to find its dependencies. i915kms didn't seem to depend on ttm. > diff --git a/sys/dev/drm2/ttm/ttm_bo.c b/sys/dev/drm2/ttm/ttm_bo.c > index 010afe6d8b3b..20083ff0fb53 100644 > --- a/sys/dev/drm2/ttm/ttm_bo.c > +++ b/sys/dev/drm2/ttm/ttm_bo.c > @@ -1498,11 +1498,11 @@ int ttm_bo_global_init(struct drm_global_reference > *ref) > tries = 0; > retry: > glob->dummy_read_page = vm_page_alloc_contig(NULL, 0, req, > - 1, 0, VM_MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); > + 1, 0, 0xfffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); > > if (unlikely(glob->dummy_read_page == NULL)) { > if (tries < 1 && vm_page_reclaim_contig(req, 1, > - 0, VM_MAX_ADDRESS, PAGE_SIZE, 0)) { > + 0, 0xfffffffful, PAGE_SIZE, 0)) { > tries++; > goto retry; > } I used VM_MAX_KERNEL_ADDRESS. kib said that it should be more related to bus spaces. 0xfffffffful seems just wrong on amd64. > Since that will eliminate the possibility that PAE is defined and giving a > bigger max. Though it also likely won't matter if you have < 4GB of RAM in > your machine. Obviously, this patch is not committable, but if it works it > tells us something. r343567 gives most of PAE including its slowness, but doesn't give full PAE due to problems with device addresses. > But as I said, I doubt this will work as there's something subtle (likely > the size of a variable or struct element) in ttm that's now out of sync. I see what look like subtle vm problems (a few frame buffer pages mismapped), but they are the same as a couple of years ago, and I don't have any devices mapped above 4G on i386. Bruce From owner-freebsd-arch@freebsd.org Thu Feb 14 21:47:28 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 339FF14E2F01 for ; Thu, 14 Feb 2019 21:47:28 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D33CC8D5E2 for ; Thu, 14 Feb 2019 21:47:26 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-ot1-x342.google.com with SMTP id i5so13138010oto.9 for ; Thu, 14 Feb 2019 13:47:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Sccg4DIZjmUqIHgrd1gyONzite+uGUiq4jMtLkHqM5U=; b=Zphv9PrGyLSWNlxbcKcD9Xb2uQ5ZB1I09K6nni/Lx5NgaUkCoCg2qzwwjwrKHoba1y okDadilFubkZI/nmfYsXrRgrFVM9nLmC6nLu3MYYsno/TIpdwCOm2PZd0Wy1Bwbxsb4X leQqemcG+9HT+OsMPmKToIwyCPG9sng8WOlRmYgUEW8pCLxMY+h3F+Pqz1sHaYTVfybf dq9W/9ShwKM1pp4WrpQEpf2r7YJO9gl8rKEMR/Yq3MQPKPlaV9OeyPT/gnWng6pt1A4l y8NIo3YBFefFIIWrl6WZniRkwQIt4y1QbSyMdoSkssBS2erqBffS+xydWflo3zZVcxHA qJZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=Sccg4DIZjmUqIHgrd1gyONzite+uGUiq4jMtLkHqM5U=; b=F8xtMSQDD97gQtuYNOXc35Agk7R1wiTrjxvy8BuwEQCiCmCGkSJVM7KIHRTZB3e9LC /+dSeY8qofn3Xw1ISsDYTOXYeb6Zzctez7rQe/gQvXWZdJEEiU3PKCyAKt8IUsQCtAM5 5/NyDyCjYJpKFDfcBEHemMAXc3mlvWbxU/hVpX6O1JEy613lpIluaFd0XDaUAgxH8Ya0 VSVKqUVVdjxvWddtmvxhalh+qGrJEF0itUX+JtFOgDnXj5eLVWh7LLpmRw0elsFBB/Fx VsAxEq7BW3asUniDZbpPugQV5lGSJa8LoQa2YdLy5zBZawPd3oVYukbQGUddJ/SuI51F JnbQ== X-Gm-Message-State: AHQUAubJZ04LcYQu8yGqKGEKI+z5pePFwMYLdloFvPTEWo1TZvHUuKVY Fy+LzrzD1y0D+EkdpsrAd/v5Oy2v X-Google-Smtp-Source: AHgI3Iatk9YP+53zebKwuYGsaDTwwDXit7BcEUDFdWGivTSbXE6AaSLmuV413DbMI77hdgxmbyPSIQ== X-Received: by 2002:aca:5284:: with SMTP id g126mr3803241oib.31.1550180845562; Thu, 14 Feb 2019 13:47:25 -0800 (PST) Received: from [192.168.1.33] ([81.174.250.12]) by smtp.gmail.com with ESMTPSA id p24sm1428823otl.64.2019.02.14.13.47.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 13:47:24 -0800 (PST) Subject: Re: "DRM removal soon" is premature To: freebsd-arch@freebsd.org References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190215065959.S4212@besplex.bde.org> From: Johannes Lundberg Openpgp: preference=signencrypt Autocrypt: addr=johalun0@gmail.com; keydata= mQINBFxFmoIBEADoFO5jY+Fmsg44KiZjufEmpEf4kt7nCOfxNG9SruWpoXUaq0B296F+fIZC hNZqv1v7lGTsfoWRusxJmLd5CQgHHxEyruZbbPpNsQ/JKoDY3GGmrmWfN/SX3y0t0kdB9HsW mJcvZhK7we52f4gxddIVBS9nQoVoONX+hzXf8zwOAa0ik0EPgEwpIKS4j9lLq4bU+mqVKdRR bPeDujEA/qbsCKhaFJkPzXZtzEe6srq4RK1doEztwnKz02b+8gs642TRkWDQeTRZputrAaoN Un4R76A1QpXWyrFG1dQu48IGHi3KbkrvNyq6R1aUBIA0+CG1npIbxmc2mtSjoyvdipmDRbBD +mhECIxmYfBT6818zuj91XjrfOyfVdV2BryBvqFkJLkS3N3QElBIiVdDgdrqiNFWiOlDMxNI tdP16oQBNo8IB27/0YHpnQEw1MafZv5gG5DO0zLtLy88ASAfL7BYf90JP19rT4JIwnxsXxyv kEJnzhsXf0QVObEiAu1MqeFyWfZ8PpunmvEmJ0VChOL+v/kIx1E9cxhhzMZhqiMXfyM4zx2+ BF1FwAwJYPuJLu2B3L0uVBu+M1YvSOmKAbXPDP8PsqPjgSBTYI51MUjuuxN6jSsHDuK6G5k4 pUWR8axa+wafhd6Vz8zVwdTJZ9LdxgLLVg0kprBgccPHhPAZVQARAQABtCZKb2hhbm5lcyBM dW5kYmVyZyA8am9oYWx1bjBAZ21haWwuY29tPokCVAQTAQgAPhYhBIl1Pb3+hI60ivmRSULn yG4BGvSeBQJcRZqCAhsjBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEELnyG4B GvSe9O0P/RzeQAu1R37RlONZTXNn+qIAHvHbZEhzrCibzaZnwYdC31wGrYmXNDyiQIqOngFf QJuufQtH/+95OESJsjR+42L/pNfFdaEWxiI003qE7uCMzLK5UWUXd/5d5vYY0CaPyNCj1tyM ZIq7x4CaR3QLTh/Fw4zMUI/ZPH2S5SxVFGv0ZZFAdNYILD3qCkAS/9HmXsqufBWbfutA8TTf wyJfywmvf7ENjlZ4QOjb242ZY9NndqbmqTgWVAws+PN5e9AT8HkadscCTCSkYnxJyYG2El27 DpAAkekYplb/C0j82KSz2fy9RgwD+tTqt88DJOeFbIbrYt44u7KLHpzaZeqyUtn0reHCkE0W lnKH2kXXbuswFB4sONxI/J5+qSmOsAm5ItO3voyjm/swpmFR1yBlxo4th26gbO5NfBOK9YsY zHKgiRDv6ZdnHo+htphRxcCDHsFPzkQe5jouI25dvMZYl1LaTS/09lwYVwVIB2SFmMtFZ7rB N4NBSzPlpsg+g4dJNqiw6Rfa2Q/wUv+MzTJgLtHjDccXlpm33Nc09UytHFtNn26PO/zrM39r TwzdLu1mg0x2WWEWTIqe4CaczQU9SIg49BSyJNoPSZx3V7nMhTKbOeQKR5aV3dXI66aENw86 pa1tipuUKCPmope/GTJatUgPiD3JkyiD+7c1zQX2UAGmuQINBFxFmoIBEACb55RAkM59huAx 4Ddd8WBjsw25qf7rzxeRKAQ7or/8LvJBYQDPXZy0RhkRiu+P+MjxwGb6HVh+LDyAYDn9d8Mt ZqCP/dOGNcl7pkb6IhfRc3i5neckXCYfbm0cigiX9JkqZSt3KT96zbjCxsFZKyIyEFsMl46q 7wKWK5Irj3zxV/Z51JNTJyMLcIRWhY8G6qlMNFgZkz2Hv63w6BRekKVImOmOdThLAscy5ybq 2CIUeAwPG7lMYG9rgcPdn3tMPeWlLmUmi5pSwOQ3AKg3xFrW3WfegjRHdqpeuXoeTjYPPCW4 gyl59uv6E12a6eivItCxj67vlBXgOr4um+zoPyXG/WfidIFtWaEgyBrlGR1Klk7SIcqjEHUA FdiM+PweY4opHXXKn60NOZCqBJ59K43drOQgRouz8E2T3yEoYg40xAfY3lhJV/Vx5+kSTjmy sT2xotlPn/GzfaAEvNuJDK+Mec3LvfbbDoOWFolNyEvoMQqF5Q3A8eGqYsoVGBPxyzNvF2iY LkymxiXpgrSN0Q/LOK7pFlWwbVC8Z6g5I0J9ecgD55dGLoX2luLir787XX/JxGffzbRnP9NE ifenJGrQmx4CyEaz/CHQqSbROm5Uo/YFUX9J7OfUO4mtu90j773j32I3psey/Fz3EC/A2PHv Ghb0KsWYpS3Pj5TV1gGyswARAQABiQI8BBgBCAAmFiEEiXU9vf6EjrSK+ZFJQufIbgEa9J4F AlxFmoICGwwFCQlmAYAACgkQQufIbgEa9J7qOQ//YG/4e69YTSjtiYLXzBI8tRU2Sx+NFByx zx+C/r0EBThLtgRwCqEUZRB7iIDSO8aZ0Qa3vwWRohlD1tn/LBdDFfMmuQkNVdLIrjBoGBB9 B5xHdZJ9xnTZEwpTtk6IWolT4j+8rpGemGKKiFo3X6l02On4Qb4iM7h6rcDb76mfwooNYzB3 8PPcLvyOWb/9iCXAb5N7doo5zmOl15DVwvIF04eXU0q1FFj/iS1zNmtZ5Got82O1TQFV+de4 Rb3YA80IZhhhCiHHJqkMKeKQogRqU+UNDBARUBxfUtKsJtQzTQ2JUGwkb6X6bx53FTLP6O9q hDoODVweE1LdB1k1H5Nn+gawPdRMBqj43Y2amK7KEgoTBrwU04CLpKiaAC0S+EcJFfJcwtpK k3F+uTtP/hnhFnWbn8SgRkHKXKWqSCt63NstXhMzAJut1gEzV+CcPNKqa/sFgQaYEvzCS5Kl F/PXj0++f3TIFqT+2ZNNp8Bz8dT7gh8RPPg5oYQiCHH8K1RAmq7gKqmwyg0qgOazHnped+od X4f3qx320JAP6NP9wglDm6eht48NJzb0sffN8z34wrP66oz8oPKtS5CFV0m/384hEg0lmi3W wo2Hno7rA1etTPJX0dI6/GLlQDtNTHvKQ077HQdWVOMQVWC9j7YH7Zr9NjtOvxcNVRX3fxpJ 6CE= X-Tagtoolbar-Keys: D20190214214722429 Message-ID: <62d87c2d-2535-9bdd-c4c8-6a74121518a9@gmail.com> Date: Thu, 14 Feb 2019 21:47:22 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190215065959.S4212@besplex.bde.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Rspamd-Queue-Id: D33CC8D5E2 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=Zphv9PrG; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johalun0@gmail.com designates 2607:f8b0:4864:20::342 as permitted sender) smtp.mailfrom=johalun0@gmail.com X-Spamd-Result: default: False [-3.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.30)[-0.299,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-0.14)[ip: (3.90), ipnet: 2607:f8b0::/32(-2.56), asn: 15169(-1.98), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[2.4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 21:47:28 -0000 On 2/14/19 8:20 PM, Bruce Evans wrote: > On Thu, 14 Feb 2019, Warner Losh wrote: > >> On Thu, Feb 14, 2019 at 11:24 AM Steve Kargl < >> sgk@troutmask.apl.washington.edu> wrote: >>> ... >>> The in-tree version does not compile because someone disconnected >>> drm2 from the build.=C2=A0 r342567 would not have happen if drm2 was >>> not disconnected. >> >> Technically, it's just off by default. It's still connected to the >> build. >> We just don't have a good way to lint the code, as drm isn't in i386 >> NOTES. > > It is also only built in the modules tree if MK_MODULES_DRM2 is set (wi= th > further convolutions for MACHINE_CPU_ARCH).=C2=A0 This is apparently no= t > set set > by default or forced for universe, so drm2 doesn't get tested by univer= se > either, and even extensively tests for changes like r343567 don't notic= e > when they break it. We are working on getting CI to build and test-load kmod ports on changes in base that might cause breakage (mostly vm sub system) as soon as they are committed. > >> You might try this fix instead, though I don't think it will matter. I= >> think the breakage you're seeing is a result of a subtle dependency >> in the >> drm2/ttm code with FreeBSD's vm system. Even had it been connected to >> the >> build and fixed at the time, I don't think it would have mattered. > > Another bug in the module is that it has no man pages.=C2=A0 I used kld= load > to find its dependencies.=C2=A0 i915kms didn't seem to depend on ttm. > >> diff --git a/sys/dev/drm2/ttm/ttm_bo.c b/sys/dev/drm2/ttm/ttm_bo.c >> index 010afe6d8b3b..20083ff0fb53 100644 >> --- a/sys/dev/drm2/ttm/ttm_bo.c >> +++ b/sys/dev/drm2/ttm/ttm_bo.c >> @@ -1498,11 +1498,11 @@ int ttm_bo_global_init(struct >> drm_global_reference >> *ref) >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tries =3D 0; >> retry: >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 glob->dummy_read_page =3D vm_page= _alloc_contig(NULL, 0, req, >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, 0, VM= _MAX_ADDRESS, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 1, 0, 0x= fffffffful, PAGE_SIZE, 0, VM_MEMATTR_UNCACHEABLE); >> >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (unlikely(glob->dummy_read_pag= e =3D=3D NULL)) { >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 if (tries < 1 && vm_page_reclaim_contig(req, 1, >> -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0, VM_MAX_ADDRESS, PAGE_SIZE, 0))= { >> +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 0, 0xfffffffful, PAGE_SIZE, 0)) {= >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 tries++; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 goto retry; >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 } > > I used VM_MAX_KERNEL_ADDRESS.=C2=A0 kib said that it should be more rel= ated to > bus spaces.=C2=A0 0xfffffffful seems just wrong on amd64. > >> Since that will eliminate the possibility that PAE is defined and >> giving a >> bigger max. Though it also likely won't matter if you have < 4GB of >> RAM in >> your machine. Obviously, this patch is not committable, but if it >> works it >> tells us something. > > r343567 gives most of PAE including its slowness, but doesn't give > full PAE > due to problems with device addresses. > >> But as I said, I doubt this will work as there's something subtle >> (likely >> the size of a variable or struct element) in ttm that's now out of syn= c. > > I see what look like subtle vm problems (a few frame buffer pages > mismapped), but they are the same as a couple of years ago, and I don't= > have any devices mapped above 4G on i386. > > Bruce > _______________________________________________ > 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 Thu Feb 14 22:58:13 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4795314E5757 for ; Thu, 14 Feb 2019 22:58:13 +0000 (UTC) (envelope-from bwidawsk@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B81BC6A563; Thu, 14 Feb 2019 22:58:12 +0000 (UTC) (envelope-from bwidawsk@freebsd.org) Received: from smtp.freebsd.org (c-73-25-164-31.hsd1.or.comcast.net [73.25.164.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bwidawsk) by smtp.freebsd.org (Postfix) with ESMTPSA id 3540D95EE; Thu, 14 Feb 2019 22:58:12 +0000 (UTC) (envelope-from bwidawsk@freebsd.org) Date: Thu, 14 Feb 2019 14:58:10 -0800 From: Ben Widawsky To: Steve Kargl Cc: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature Message-ID: <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> Mail-Followup-To: Steve Kargl , Warner Losh , "freebsd-arch@freebsd.org" References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190214191739.GA68371@troutmask.apl.washington.edu> User-Agent: NeoMutt/20180716 X-Rspamd-Queue-Id: B81BC6A563 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.90 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.99)[-0.992,0]; NEURAL_HAM_SHORT(-0.91)[-0.909,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 22:58:13 -0000 On 19-02-14 11:17:39, Steve Kargl wrote: > On Thu, Feb 14, 2019 at 12:04:46PM -0700, Warner Losh wrote: > > On Thu, Feb 14, 2019 at 12:02 PM Steve Kargl < > > > > > > I can't test the patch for several hours, and it will take > > > 6 to 7 hours to rebuild world/kernel. So, I'll have to report > > > back tomorrow. > > > > > > > You'd only need to rebuild sys/modules/drm2, since that's the only thing > > that will change with the patch. > > > > But I can wait. I won't be removing things before tomorrow. > > > > Well, to get the laptop functional again, so that I could > continue testing some libm changes, I reverted trunk back > to r343566. I would need to pull in r343567 with the > pmap.h changes. Apply your patch to drm2, and rebuild the > entire kernel (including WITH_MODULE_DRM2). I don't know > if this new kernel would be incompatible with the old > world. > Not to pile on unnecessarily here, but I think the fundamental issue is that there is nobody who wants to maintain the in-tree DRM, and removal is likely a better option to half-assed maintenance. I'd imagine there'd be a different discussion if several developers were clamoring to keep this driver well maintained in the tree. -- Ben Widawsky, Intel Open Source Technology Center From owner-freebsd-arch@freebsd.org Thu Feb 14 23:30:05 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8115D14E6457 for ; Thu, 14 Feb 2019 23:30:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 04DB26B54F for ; Thu, 14 Feb 2019 23:30:03 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1ENU0a8003427 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 14 Feb 2019 15:30:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1ENU0LP003426; Thu, 14 Feb 2019 15:30:00 -0800 (PST) (envelope-from sgk) Date: Thu, 14 Feb 2019 15:30:00 -0800 From: Steve Kargl To: Warner Losh , "freebsd-arch@freebsd.org" Subject: Re: "DRM removal soon" is premature Message-ID: <20190214233000.GA2752@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: 04DB26B54F X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.32 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_SHORT(0.73)[0.734,0]; NEURAL_HAM_LONG(-0.46)[-0.465,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_MEDIUM(0.27)[0.274,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.09)[ip: (0.17), ipnet: 128.95.0.0/16(0.24), asn: 73(0.10), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 23:30:05 -0000 On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote: > > Not to pile on unnecessarily here, but I think the fundamental issue is that > there is nobody who wants to maintain the in-tree DRM, and removal is likely a > better option to half-assed maintenance. I'd imagine there'd be a different > discussion if several developers were clamoring to keep this driver well > maintained in the tree. > Unhooking a driver from the build, so that it cannot expose a change that breaks said driver is certainly a way to ensure the driver is not maintained. Wasted a weekend trying to find and attempting to fix the damage caused by a change in src/sys to the drm-legacy-kmod port. You know, the port that was promised as part of the drm2 removal. I would have spent this weekend testing changes to cexp, cexpf, the soon-to-be-submitted cexpl, ccosh, ccoshf, and the soon-to-be-submitted ccoshl. That's all on hold now as I'm not sure when I'll be able to carve out time for testing. -- Steve From owner-freebsd-arch@freebsd.org Thu Feb 14 23:39:56 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 348F614E691F for ; Thu, 14 Feb 2019 23:39:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 099EC6BB44 for ; Thu, 14 Feb 2019 23:39:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x72a.google.com with SMTP id y195so4677016qka.12 for ; Thu, 14 Feb 2019 15:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=crl/Jfw+KrP7qohShKzd9MkMnjgQDem6tH0qDCLysLs=; b=A65Zfv5VNpk1KIqOR+cZE62R1gIKlUn0cVPSufIVub47pR+u/lCS8ZgGWyOSRkeZcN 1jBBOE7vH8yLMOtAgKvzK6COJTuyGwSSTkscUiStmzQ6DZ9ifT23DxD90GuQl5ysbPBj 6hjN2FHz8qFKlfv1B42HkpeCbBUuZfnIpwXWzVoDUO0F9bYHKUoX9a0Ywa5WS4NEOPQA neYVWwfziqYj0lTvmqUNXRbF1ps29nlXqDh8CQv+vZUBQ4eFN9VEcyBTkFsLJ/xHwuQd /nnD57UZXfckVrkNfT0RcHl3lQR1agu7P5NyF6wZkUc7aSEz86c3UUX4sVvcXyPBVcjR RjFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=crl/Jfw+KrP7qohShKzd9MkMnjgQDem6tH0qDCLysLs=; b=WTp9xmArZjBNeedkCk8Xo1qVI11srr/ZXGSQ/pumrz3ijIpFel7Hj4ldsUvMl2doh2 6xPOeQOSoUAY74JbYZJ8mK4NMAGAcfdgTwzxsK/0dMJYCpq/qOtXm6SxXPVHYULPdvKn 3oBgbUKWgNispxfwgAKJtDrH0UJvF67fQ9dzlJfmD5HKtzk13mxq9OnZnW08kfI590SK 8APPb8eEwRAanCa3cHJMfcH8Uy9Udb3RYLfDamtyZC7ex7B/1fXZ2voVwwi6GFaCZWQf rQbKbYKtgIbfLQpnGkwu0V/frbBcyQogZUxYyeEyELy7P2jDOHAADkH3zbpOy2Hlyb+w BWuQ== X-Gm-Message-State: AHQUAubGTJROZCpmPFsV99PMnykCNuBSeD0hcHSUkeXOzhjpaCehp+Ki TYFViyL4rT+Db6Ijdlg+FbsqzlEKXmB06nqYfAiHWzHf X-Google-Smtp-Source: AHgI3IaGP9JF3TyQmgCJtz/B1fY+OvBWEQ36ZtLPCoKS/wGU1Ktzc5cmUUXiZ4PTBq2TBwJSoB18ra5uETY8tvMXP8g= X-Received: by 2002:a37:9201:: with SMTP id u1mr5054829qkd.258.1550187594349; Thu, 14 Feb 2019 15:39:54 -0800 (PST) MIME-Version: 1.0 References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> In-Reply-To: <20190214233000.GA2752@troutmask.apl.washington.edu> From: Warner Losh Date: Thu, 14 Feb 2019 16:39:42 -0700 Message-ID: Subject: Re: "DRM removal soon" is premature To: Steve Kargl Cc: freebsd-arch@freebsd.org X-Rspamd-Queue-Id: 099EC6BB44 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=A65Zfv5V X-Spamd-Result: default: False [-5.76 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; URIBL_BLOCKED(0.00)[gappssmtp.com.multi.uribl.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.96)[-0.959,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[a.2.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[ALT1.aspmx.l.google.com,aspmx.l.google.com,ALT2.aspmx.l.google.com]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; IP_SCORE(-2.79)[ip: (-9.32), ipnet: 2607:f8b0::/32(-2.56), asn: 15169(-1.98), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2019 23:39:56 -0000 On Thu, Feb 14, 2019, 4:30 PM Steve Kargl On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote: > > > > Not to pile on unnecessarily here, but I think the fundamental issue is > that > > there is nobody who wants to maintain the in-tree DRM, and removal is > likely a > > better option to half-assed maintenance. I'd imagine there'd be a > different > > discussion if several developers were clamoring to keep this driver well > > maintained in the tree. > > > > Unhooking a driver from the build, so that it cannot expose > a change that breaks said driver is certainly a way to > ensure the driver is not maintained. > It was already unmaintained. Wasted a weekend trying to find and attempting to fix the > damage caused by a change in src/sys to the drm-legacy-kmod > port. You know, the port that was promised as part of the > drm2 removal. I would have spent this weekend testing > changes to cexp, cexpf, the soon-to-be-submitted cexpl, > ccosh, ccoshf, and the soon-to-be-submitted ccoshl. That's > all on hold now as I'm not sure when I'll be able to carve > out time for testing. > That is unfortunate. The root cause though is that the config you are using is on the trailing edge. It would have been fixed, in that it would have built, but I'm pretty sure it would have still broken because no one is using this config. I'd argue that having it in the tree too long, including in 12, lead to an expectation that would continue to work when we knew a year ago there was a high risk of undetected breakage happening. And wasting your time because of those unrealistic expectations we've fostered is definitely not a good outcome. So I too am frustrated. And I'm sorry that it is causing you pain. Warner > From owner-freebsd-arch@freebsd.org Fri Feb 15 01:16:36 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48C0714E99B4 for ; Fri, 15 Feb 2019 01:16:36 +0000 (UTC) (envelope-from parker@iownkeywords.com) 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 6CDF16EE83 for ; Fri, 15 Feb 2019 01:16:35 +0000 (UTC) (envelope-from parker@iownkeywords.com) Received: by mailman.ysv.freebsd.org (Postfix) id 2C4E014E99AE; Fri, 15 Feb 2019 01:16:35 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFA6614E99AB for ; Fri, 15 Feb 2019 01:16:34 +0000 (UTC) (envelope-from parker@iownkeywords.com) Received: from a2nlsmtp01-05.prod.iad2.secureserver.net (a2nlsmtp01-05.prod.iad2.secureserver.net [198.71.225.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "relay-hosting.secureserver.net", Issuer "Starfield Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 824886EE7E for ; Fri, 15 Feb 2019 01:16:34 +0000 (UTC) (envelope-from parker@iownkeywords.com) Received: from a2plcpnl0697.prod.iad2.secureserver.net ([198.71.240.17]) by : HOSTING RELAY : with ESMTP id uRnrgabHsVVmMuRnrgbffl; Thu, 14 Feb 2019 17:56:31 -0700 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=iownkeywords.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Message-ID:Subject:Reply-To:From:To:Date:Sender:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=yWKcH9y/uQKPDwa+Z0AG/bsh9cEvRLocbGNZsvW8Kl4=; b=fDTf/NhHvi+eF1ee2n3iinIfrl X/c1WzfQmjFR8s/mQFJMIdDDdrACMhW6i4KxbcJrSACxzDxC4Ostygu3cCbQt8bzbGUSD1U6x1tEG DRx94ZLaGKFohifA5SBriBwsOuAFSaB3gAGD8zvO6DIXrb7k4wLdBkjmFviPGLf4pL0gPwLbqa13Z cmHk3T24U6jH+t5LwrAa6rXmfqtdzf42PzLNuulvFpBQS4a9GA2fUPAf+62WcOiuw+D8jeK3zPIc7 dyFpUrsp92S3wDJOQqj4MKS6LwE23yE14Fr/YmsTBCqQy3Dza99WsUK6j8cZy79qlkYxA+Rs9QHLt maeoJfpg==; Received: from [127.0.0.1] (port=39211 helo=iownkeywords.com) by a2plcpnl0697.prod.iad2.secureserver.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1guRnr-008Bhq-98 for arch@freebsd.org; Thu, 14 Feb 2019 17:56:31 -0700 Date: Fri, 15 Feb 2019 00:56:26 +0000 To: "arch@freebsd.org" From: "parker@iownkeywords.com" Reply-To: "parker@iownkeywords.com" Subject: Re: Email address not in use Message-ID: X-Mailer: PHPMailer 5.2.22 (https://github.com/PHPMailer/PHPMailer) MIME-Version: 1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2plcpnl0697.prod.iad2.secureserver.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - iownkeywords.com X-Get-Message-Sender-Via: a2plcpnl0697.prod.iad2.secureserver.net: authenticated_id: parker@iownkeywords.com X-Authenticated-Sender: a2plcpnl0697.prod.iad2.secureserver.net: parker@iownkeywords.com X-Source: X-Source-Args: X-Source-Dir: X-CMAE-Envelope: MS4wfFaG4hABJmBgNrTWjlp0vQCjr9o8qIR/Efd1/+mc49OUJhdYTTAlJDmnhcEQJX5LoTxLMAFws1w2MvsTEW+xdDEd5Hx3F0Zzn3rOiG2KUBISxfBQmen8 w7dwu3CQ1rzrv9WBr1LePUR6gRcyMmDxu+cwiQhepl8lXhrbS45t8FlZhd/TfNIt6/Jry/roMGV2Uh9QOwprSjicmHsNXH/05lk= X-Rspamd-Queue-Id: 824886EE7E X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=none (invalid DKIM record) header.d=iownkeywords.com header.s=default header.b=fDTf/NhH X-Spamd-Result: default: False [6.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_REPLYTO(0.00)[parker@iownkeywords.com]; MX_INVALID(0.50)[cached]; HAS_X_SOURCE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[iownkeywords.com:~]; HAS_X_ANTIABUSE(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; IP_SCORE(0.73)[ip: (2.58), ipnet: 198.71.224.0/21(0.89), asn: 26496(0.24), country: US(-0.07)]; ASN(0.00)[asn:26496, ipnet:198.71.224.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; HAS_X_AS(0.00)[parker@iownkeywords.com]; ARC_NA(0.00)[]; FAKE_REPLY(1.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_DN_EQ_ADDR(1.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(0.98)[0.975,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; HAS_PHPMAILER_SIG(0.00)[]; DMARC_NA(0.00)[iownkeywords.com]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[1.000,0]; RCVD_IN_DNSWL_NONE(0.00)[49.225.71.198.list.dnswl.org : 127.0.5.0]; R_DKIM_PERMFAIL(0.00)[iownkeywords.com:s=default]; R_SPF_NA(0.00)[]; TO_DN_EQ_ADDR_ALL(0.00)[]; HAS_X_GMSV(0.00)[parker@iownkeywords.com]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 01:16:36 -0000 Greetings, This email address is temporarily not monitored. Best Regards, Parker Bowers From owner-freebsd-arch@freebsd.org Fri Feb 15 09:07:14 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DFC4014D0FC6 for ; Fri, 15 Feb 2019 09:07:13 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CDAB986930 for ; Fri, 15 Feb 2019 09:07:12 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-ot1-x32d.google.com with SMTP id s5so15376913oth.7 for ; Fri, 15 Feb 2019 01:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7VErtvNaF4UKWech5s+s4Md+sT0v37iJKOlTZoGL0PI=; b=acW6gOTW8gVNt5HNUR1t3xHC0FkR0p68mCnZ1fSjqQI6YQerWESbKiHIr8uRN2WKLp vs1SuDr/R44/4WRc7P4G8D6ttGo00D6LmhRB1o5YnnGuEMusH1UN9BcvpO1Y+A95Yu5f XIon/R6R7rRFT61/gqwbNslzfnDDdGIV8C4hcE4MTyMvYwmRcfEvI/ozJCAQDS9aUv77 fRTjCDfymNe1Yx7oyMFLpkwWZjC/BacMPclmuMa8/r1R+G3DXq5wUhqiFWTKWg18ictt gswERa+bol4/XIg1Es8nlHXo1iErqrEdlo7Cn+qZGfYle/zuu8EAnfRSOKjvA9SlMmEM 8ORg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding:content-language; bh=7VErtvNaF4UKWech5s+s4Md+sT0v37iJKOlTZoGL0PI=; b=gRYo++iTKAUQp2puG4KxvqUKrzdfgekAGfGiw1A8a8cejYTIUKqnRviiCJKL6T6TYe 6mJ1+B1MV7tMoio0SqVurW9X7NBrzChoCk9F0qg7/IjH0+1vy1xsgRJNf5CVVuz47mWV UXUQznGI4qzFVI86fZ4wh1olTylok9qBi4oGGh6azZZO4c+MfFH+gFD8lJB6KWoHF+EG /kPtdR/alkw+e7Fl7whoYiLCG6jKhBHHVDI1Cf+1odFTRlPZkVHkY4UTr+Z9eBUYWqfV vk6i/6ARUViLOY7nGxhL2N+beKNE9Y8/vgqTTePuibDX8FxVltClIlbRQia+C2SSMZLP 0oFw== X-Gm-Message-State: AHQUAuYezzjcO/Z1Cgu7RPlZVek7wSpZI7rScSX69cksEOi7L1DY/bTa t+ZGCV3ajXjWusHe9kwC84s+hIIT X-Google-Smtp-Source: AHgI3IbhX2tWfDPP8o2zupL0r1kIa1UsqpUHS9LMoMSr/VlxvvEO9+OKOw7HqZYN+6Ld+o8wmLt6fg== X-Received: by 2002:a9d:66c9:: with SMTP id t9mr4995423otm.36.1550221631149; Fri, 15 Feb 2019 01:07:11 -0800 (PST) Received: from [192.168.1.33] ([81.174.250.12]) by smtp.gmail.com with ESMTPSA id s66sm3970497oia.55.2019.02.15.01.07.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Feb 2019 01:07:10 -0800 (PST) Subject: Re: "DRM removal soon" is premature To: freebsd-arch@freebsd.org References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> From: Johannes Lundberg Openpgp: preference=signencrypt Autocrypt: addr=johalun0@gmail.com; keydata= mQINBFxFmoIBEADoFO5jY+Fmsg44KiZjufEmpEf4kt7nCOfxNG9SruWpoXUaq0B296F+fIZC hNZqv1v7lGTsfoWRusxJmLd5CQgHHxEyruZbbPpNsQ/JKoDY3GGmrmWfN/SX3y0t0kdB9HsW mJcvZhK7we52f4gxddIVBS9nQoVoONX+hzXf8zwOAa0ik0EPgEwpIKS4j9lLq4bU+mqVKdRR bPeDujEA/qbsCKhaFJkPzXZtzEe6srq4RK1doEztwnKz02b+8gs642TRkWDQeTRZputrAaoN Un4R76A1QpXWyrFG1dQu48IGHi3KbkrvNyq6R1aUBIA0+CG1npIbxmc2mtSjoyvdipmDRbBD +mhECIxmYfBT6818zuj91XjrfOyfVdV2BryBvqFkJLkS3N3QElBIiVdDgdrqiNFWiOlDMxNI tdP16oQBNo8IB27/0YHpnQEw1MafZv5gG5DO0zLtLy88ASAfL7BYf90JP19rT4JIwnxsXxyv kEJnzhsXf0QVObEiAu1MqeFyWfZ8PpunmvEmJ0VChOL+v/kIx1E9cxhhzMZhqiMXfyM4zx2+ BF1FwAwJYPuJLu2B3L0uVBu+M1YvSOmKAbXPDP8PsqPjgSBTYI51MUjuuxN6jSsHDuK6G5k4 pUWR8axa+wafhd6Vz8zVwdTJZ9LdxgLLVg0kprBgccPHhPAZVQARAQABtCZKb2hhbm5lcyBM dW5kYmVyZyA8am9oYWx1bjBAZ21haWwuY29tPokCVAQTAQgAPhYhBIl1Pb3+hI60ivmRSULn yG4BGvSeBQJcRZqCAhsjBQkJZgGABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEELnyG4B GvSe9O0P/RzeQAu1R37RlONZTXNn+qIAHvHbZEhzrCibzaZnwYdC31wGrYmXNDyiQIqOngFf QJuufQtH/+95OESJsjR+42L/pNfFdaEWxiI003qE7uCMzLK5UWUXd/5d5vYY0CaPyNCj1tyM ZIq7x4CaR3QLTh/Fw4zMUI/ZPH2S5SxVFGv0ZZFAdNYILD3qCkAS/9HmXsqufBWbfutA8TTf wyJfywmvf7ENjlZ4QOjb242ZY9NndqbmqTgWVAws+PN5e9AT8HkadscCTCSkYnxJyYG2El27 DpAAkekYplb/C0j82KSz2fy9RgwD+tTqt88DJOeFbIbrYt44u7KLHpzaZeqyUtn0reHCkE0W lnKH2kXXbuswFB4sONxI/J5+qSmOsAm5ItO3voyjm/swpmFR1yBlxo4th26gbO5NfBOK9YsY zHKgiRDv6ZdnHo+htphRxcCDHsFPzkQe5jouI25dvMZYl1LaTS/09lwYVwVIB2SFmMtFZ7rB N4NBSzPlpsg+g4dJNqiw6Rfa2Q/wUv+MzTJgLtHjDccXlpm33Nc09UytHFtNn26PO/zrM39r TwzdLu1mg0x2WWEWTIqe4CaczQU9SIg49BSyJNoPSZx3V7nMhTKbOeQKR5aV3dXI66aENw86 pa1tipuUKCPmope/GTJatUgPiD3JkyiD+7c1zQX2UAGmuQINBFxFmoIBEACb55RAkM59huAx 4Ddd8WBjsw25qf7rzxeRKAQ7or/8LvJBYQDPXZy0RhkRiu+P+MjxwGb6HVh+LDyAYDn9d8Mt ZqCP/dOGNcl7pkb6IhfRc3i5neckXCYfbm0cigiX9JkqZSt3KT96zbjCxsFZKyIyEFsMl46q 7wKWK5Irj3zxV/Z51JNTJyMLcIRWhY8G6qlMNFgZkz2Hv63w6BRekKVImOmOdThLAscy5ybq 2CIUeAwPG7lMYG9rgcPdn3tMPeWlLmUmi5pSwOQ3AKg3xFrW3WfegjRHdqpeuXoeTjYPPCW4 gyl59uv6E12a6eivItCxj67vlBXgOr4um+zoPyXG/WfidIFtWaEgyBrlGR1Klk7SIcqjEHUA FdiM+PweY4opHXXKn60NOZCqBJ59K43drOQgRouz8E2T3yEoYg40xAfY3lhJV/Vx5+kSTjmy sT2xotlPn/GzfaAEvNuJDK+Mec3LvfbbDoOWFolNyEvoMQqF5Q3A8eGqYsoVGBPxyzNvF2iY LkymxiXpgrSN0Q/LOK7pFlWwbVC8Z6g5I0J9ecgD55dGLoX2luLir787XX/JxGffzbRnP9NE ifenJGrQmx4CyEaz/CHQqSbROm5Uo/YFUX9J7OfUO4mtu90j773j32I3psey/Fz3EC/A2PHv Ghb0KsWYpS3Pj5TV1gGyswARAQABiQI8BBgBCAAmFiEEiXU9vf6EjrSK+ZFJQufIbgEa9J4F AlxFmoICGwwFCQlmAYAACgkQQufIbgEa9J7qOQ//YG/4e69YTSjtiYLXzBI8tRU2Sx+NFByx zx+C/r0EBThLtgRwCqEUZRB7iIDSO8aZ0Qa3vwWRohlD1tn/LBdDFfMmuQkNVdLIrjBoGBB9 B5xHdZJ9xnTZEwpTtk6IWolT4j+8rpGemGKKiFo3X6l02On4Qb4iM7h6rcDb76mfwooNYzB3 8PPcLvyOWb/9iCXAb5N7doo5zmOl15DVwvIF04eXU0q1FFj/iS1zNmtZ5Got82O1TQFV+de4 Rb3YA80IZhhhCiHHJqkMKeKQogRqU+UNDBARUBxfUtKsJtQzTQ2JUGwkb6X6bx53FTLP6O9q hDoODVweE1LdB1k1H5Nn+gawPdRMBqj43Y2amK7KEgoTBrwU04CLpKiaAC0S+EcJFfJcwtpK k3F+uTtP/hnhFnWbn8SgRkHKXKWqSCt63NstXhMzAJut1gEzV+CcPNKqa/sFgQaYEvzCS5Kl F/PXj0++f3TIFqT+2ZNNp8Bz8dT7gh8RPPg5oYQiCHH8K1RAmq7gKqmwyg0qgOazHnped+od X4f3qx320JAP6NP9wglDm6eht48NJzb0sffN8z34wrP66oz8oPKtS5CFV0m/384hEg0lmi3W wo2Hno7rA1etTPJX0dI6/GLlQDtNTHvKQ077HQdWVOMQVWC9j7YH7Zr9NjtOvxcNVRX3fxpJ 6CE= X-Tagtoolbar-Keys: D20190215090708036 Message-ID: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> Date: Fri, 15 Feb 2019 09:07:08 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <20190214233000.GA2752@troutmask.apl.washington.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Rspamd-Queue-Id: CDAB986930 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=acW6gOTW; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johalun0@gmail.com designates 2607:f8b0:4864:20::32d as permitted sender) smtp.mailfrom=johalun0@gmail.com X-Spamd-Result: default: False [-6.68 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.94)[-0.943,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; IP_SCORE(-2.72)[ip: (-8.99), ipnet: 2607:f8b0::/32(-2.57), asn: 15169(-1.99), country: US(-0.07)]; RCVD_IN_DNSWL_NONE(0.00)[d.2.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 09:07:14 -0000 On 2/14/19 11:30 PM, Steve Kargl wrote: > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote: >> Not to pile on unnecessarily here, but I think the fundamental issue i= s that >> there is nobody who wants to maintain the in-tree DRM, and removal is = likely a >> better option to half-assed maintenance. I'd imagine there'd be a diff= erent >> discussion if several developers were clamoring to keep this driver we= ll >> maintained in the tree. >> > Unhooking a driver from the build, so that it cannot expose > a change that breaks said driver is certainly a way to=20 > ensure the driver is not maintained. > > Wasted a weekend trying to find and attempting to fix the > damage caused by a change in src/sys to the drm-legacy-kmod > port. You know, the port that was promised as part of the > drm2 removal. I would have spent this weekend testing=20 > changes to cexp, cexpf, the soon-to-be-submitted cexpl, > ccosh, ccoshf, and the soon-to-be-submitted ccoshl. That's > all on hold now as I'm not sure when I'll be able to carve > out time for testing. This happens all time for me with virtualbox-kmod as well in current. Changes to src breaks certain (kmod) ports and there's always a delay until they are fixed. This is life in -CURRENT. I accept this and don't go bitching to virtualbox-kmod maintainers about it. Your usage is an edge case so naturally there will be a longer delay before breakage is noticed, until we can get automated CI up and running (even so, there will be a delay). With graphics, there's a software fallback (vesa/scfb), virtualbox has no such option. For stable usage, there are -RELEASE options. From owner-freebsd-arch@freebsd.org Fri Feb 15 09:44:06 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A043214D31AD for ; Fri, 15 Feb 2019 09:44:06 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1F64A88437 for ; Fri, 15 Feb 2019 09:44:05 +0000 (UTC) (envelope-from oliver.pinter@hardenedbsd.org) Received: by mail-yb1-xb2e.google.com with SMTP id j85so206571ybg.11 for ; Fri, 15 Feb 2019 01:44:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KJmGOIZnn4O/KKiFava2RWSNMaghn/w5nNv8JT4fhq4=; b=IKnFKEYlH6KOoeKxn+zQVRvz1eVkKNNG4F4BooPgKOmjFwFStTG3nuigdqQPxytky9 Z3YvJCNUErbrzCJLRtSns4xUmp3TvDmypCLv2OtTghNvuJmTjzRmJfhcbjXGOB79xBVD jzgp+7YIH0ZXIiolRrmE588tYDCKPGzCiSAERflLAmnPix5/VR6pMgxajAssSnbWL9rb ACsUXaIHCvDWDYnvTiqnt13OtFv+TGRcgGz9JqqtORV82DQtvYJkO/5VG6xb43Njz8r7 eZ9hwVzsr2pn2NODn2yFK31NszzZOOJ305FEq94DE6syiPUqvQ4374ZXg82Y6UEi29ow tOOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KJmGOIZnn4O/KKiFava2RWSNMaghn/w5nNv8JT4fhq4=; b=DpbYpqXmppQDJqV9f0Zf7rSdasgqRQixCG9sJjcnvg7PPwLxy7vkvqhZhgA7Fj3jq+ T8hwSSqbRAqiQdWAbs6ZRt3Of1cYL1TWskQ+qkV0Bdk8VhjgTRLna184G2zc1/P18b14 ohGwLcZ6XB0zAHAdrGO0ksBPMLNzMPFvNWIQVw3Nkz9Oi1ZzsL370u5lBKSWj00BopQ7 uZj5NbJ4wDW2PGUcfY2Ri+4zitX5GACP9i07bd+2aHTzF5kYOM2KQ+Ib+MxHdbV1kigS sxGL3CqH7LmEMzJophp51rznjLb8st0g5vU/mcAjW+ahe4vbgByZ+4c42nkyiUjAQpJj bL4Q== X-Gm-Message-State: AHQUAuZ/OzzBBZvmkCr+YZ9ZPjB0r7WaEMpMZYW4ENaxZmboI8QEwVu5 JwxVsRrGfPIYld5bTwS8Q0/EndtQPvi2si8eHfe9jw== X-Google-Smtp-Source: AHgI3Ib/+TkRpqgpRg2F10H/RHJTAec2CNODfq8fNiWMEF20yOscqusJcOYPXr0C5GVQLoJ3MudHd7WC2MvQPEpKtoE= X-Received: by 2002:a25:da95:: with SMTP id n143mr6927119ybf.488.1550223844324; Fri, 15 Feb 2019 01:44:04 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:ae8e:0:0:0:0:0 with HTTP; Fri, 15 Feb 2019 01:44:03 -0800 (PST) In-Reply-To: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> From: Oliver Pinter Date: Fri, 15 Feb 2019 10:44:03 +0100 Message-ID: Subject: Re: "DRM removal soon" is premature To: Johannes Lundberg Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 1F64A88437 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=hardenedbsd.org header.s=google header.b=IKnFKEYl; spf=pass (mx1.freebsd.org: domain of oliver.pinter@hardenedbsd.org designates 2607:f8b0:4864:20::b2e as permitted sender) smtp.mailfrom=oliver.pinter@hardenedbsd.org X-Spamd-Result: default: False [-6.35 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[e.2.b.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,aspmx2.googlemail.com,alt2.aspmx.l.google.com,aspmx3.googlemail.com]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; IP_SCORE(-2.86)[ip: (-9.65), ipnet: 2607:f8b0::/32(-2.57), asn: 15169(-1.99), country: US(-0.07)] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 09:44:06 -0000 On Friday, February 15, 2019, Johannes Lundberg wrote: > > On 2/14/19 11:30 PM, Steve Kargl wrote: > > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote: > >> Not to pile on unnecessarily here, but I think the fundamental issue is > that > >> there is nobody who wants to maintain the in-tree DRM, and removal is > likely a > >> better option to half-assed maintenance. I'd imagine there'd be a > different > >> discussion if several developers were clamoring to keep this driver well > >> maintained in the tree. > >> > > Unhooking a driver from the build, so that it cannot expose > > a change that breaks said driver is certainly a way to > > ensure the driver is not maintained. > > > > Wasted a weekend trying to find and attempting to fix the > > damage caused by a change in src/sys to the drm-legacy-kmod > > port. You know, the port that was promised as part of the > > drm2 removal. I would have spent this weekend testing > > changes to cexp, cexpf, the soon-to-be-submitted cexpl, > > ccosh, ccoshf, and the soon-to-be-submitted ccoshl. That's > > all on hold now as I'm not sure when I'll be able to carve > > out time for testing. > > This happens all time for me with virtualbox-kmod as well in current. > Changes to src breaks certain (kmod) ports and there's always a delay > until they are fixed. This is life in -CURRENT. I accept this and don't > go bitching to virtualbox-kmod maintainers about it. Your usage is an > edge case so naturally there will be a longer delay before breakage is > noticed, until we can get automated CI up and running (even so, there > will be a delay). > > With graphics, there's a software fallback (vesa/scfb), virtualbox has > no such option. bhyve, pure qumu? > > For stable usage, there are -RELEASE options. > > > > _______________________________________________ > 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 15 10:07:38 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40ECB14D401E for ; Fri, 15 Feb 2019 10:07:38 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2C7E989155 for ; Fri, 15 Feb 2019 10:07:37 +0000 (UTC) (envelope-from johalun0@gmail.com) Received: by mail-wr1-x434.google.com with SMTP id o17so9711440wrw.3 for ; Fri, 15 Feb 2019 02:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QUlvORHZydHZPUFpRZbts0JjngD0zeBT6CFJc+AY924=; b=D0clj+oEeIyduVcjRv08rM52bnCxlNUJeBwson8wBsRF0OTp6aLX2rfcBCZBNBt33F gjj5l+/cKyDUz2lZ1w53Dt+r/vWcmESZLAg7A3U+GfYTc8A8z8naa9ndUtytO7hPwKOH +Pfyx1S8ou92hFE4OGmZe7C2UkTal0YXKgbVsS8dcRmbd4mbD6CTo5QU8wOKylk+DzTx W0Vwimzscdxqz4nkFrbH1WvGC8Sk3N/fhWHrxI6KW5uVBkT+xh23Q/9xy0CexnK1J5De Th+hCBfG6UQe5psAQkH9oELK1+5m6/gdjM5xqCs+n6N5LiwHJnfrxwHteS6RRBZ6FjS4 TxYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QUlvORHZydHZPUFpRZbts0JjngD0zeBT6CFJc+AY924=; b=E1wtsiEu4J1JdwQHhvu6rCqVtzFCHZh//hOZ7PffC1UZvJ6xScAbwKNseKmy8mENwc ZpuL/qMwqf4/kcCqUsv3a2x3dxaC+3gmqdj27V3ELukNAh23ts23nyopuaqxe8Tz/x+2 xAJiYDagRKKqPhlnQmkNCm6o/FD0qptBQXsFhKFe99fhBc8IXcadKR7ECLK927hBqsD2 3GdiyTD5q4j/pEDm+AkTa/VmmpBBtrvoHNRImWb6kGN8L0EPcoDYe0jaV6B4VNadyt7o lZP+QXUB2JWBCAVJv3hsEV7rdWNs4spf8NZC2OCRyZ6ivBPo8iO7wDhKi+gZhfsqnKrW luBA== X-Gm-Message-State: AHQUAuaq0mSAtptqAMsZnqZ945aZXrara8617tpdP7CD9Sr9qxpXZ+8G YszAmE8A4Hhu1IEWN0Z4thkIbgyNus5z3nq2OawYhg== X-Google-Smtp-Source: AHgI3IZcHSB1IKM791ALDlxOyJ0/AGf9p387TDxrV+40kzK1iKNH1QlIIxzT9zmqADu9s73oJTv4+XFSQyJHw22GCJ8= X-Received: by 2002:adf:a147:: with SMTP id r7mr5982034wrr.5.1550225254809; Fri, 15 Feb 2019 02:07:34 -0800 (PST) MIME-Version: 1.0 References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> In-Reply-To: From: Johannes Lundberg Date: Fri, 15 Feb 2019 10:07:23 +0000 Message-ID: Subject: Re: "DRM removal soon" is premature To: Oliver Pinter Cc: "freebsd-arch@freebsd.org" X-Rspamd-Queue-Id: 2C7E989155 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=D0clj+oE; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of johalun0@gmail.com designates 2a00:1450:4864:20::434 as permitted sender) smtp.mailfrom=johalun0@gmail.com X-Spamd-Result: default: False [-6.80 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.98)[-0.978,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[4.3.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.5.4.1.0.0.a.2.list.dnswl.org : 127.0.5.0]; IP_SCORE(-2.81)[ip: (-9.71), ipnet: 2a00:1450::/32(-2.30), asn: 15169(-1.99), country: US(-0.07)]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 10:07:38 -0000 On Fri, Feb 15, 2019 at 09:44 Oliver Pinter wrote: > > > On Friday, February 15, 2019, Johannes Lundberg > wrote: > >> >> On 2/14/19 11:30 PM, Steve Kargl wrote: >> > On Thu, Feb 14, 2019 at 02:58:10PM -0800, Ben Widawsky wrote: >> >> Not to pile on unnecessarily here, but I think the fundamental issue >> is that >> >> there is nobody who wants to maintain the in-tree DRM, and removal is >> likely a >> >> better option to half-assed maintenance. I'd imagine there'd be a >> different >> >> discussion if several developers were clamoring to keep this driver >> well >> >> maintained in the tree. >> >> >> > Unhooking a driver from the build, so that it cannot expose >> > a change that breaks said driver is certainly a way to >> > ensure the driver is not maintained. >> > >> > Wasted a weekend trying to find and attempting to fix the >> > damage caused by a change in src/sys to the drm-legacy-kmod >> > port. You know, the port that was promised as part of the >> > drm2 removal. I would have spent this weekend testing >> > changes to cexp, cexpf, the soon-to-be-submitted cexpl, >> > ccosh, ccoshf, and the soon-to-be-submitted ccoshl. That's >> > all on hold now as I'm not sure when I'll be able to carve >> > out time for testing. >> >> This happens all time for me with virtualbox-kmod as well in current. >> Changes to src breaks certain (kmod) ports and there's always a delay >> until they are fixed. This is life in -CURRENT. I accept this and don't >> go bitching to virtualbox-kmod maintainers about it. Your usage is an >> edge case so naturally there will be a longer delay before breakage is >> noticed, until we can get automated CI up and running (even so, there >> will be a delay). >> >> With graphics, there's a software fallback (vesa/scfb), virtualbox has >> no such option. > > > bhyve, pure qumu? > Yes bhyve is awesome and I use it mostly. Don=E2=80=99t get me wrong, I=E2= =80=99m not complaining about breakage, mearly stating the fact that that=E2=80=99s lif= e in -current. VBox kmods are usually fixed quickly, I think the biggest delay is the time it takes to build all the packages. Maybe a fast lane for critical kmod ports that can be upgraded/rebuilt isolated from the rest would be something? > >> >> For stable usage, there are -RELEASE options. >> >> >> >> _______________________________________________ >> 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 15 15:50:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C4C2314DED67 for ; Fri, 15 Feb 2019 15:50:30 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "troutmask", Issuer "troutmask" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B72166F322 for ; Fri, 15 Feb 2019 15:50:28 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id x1FFoQSt009386 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Feb 2019 07:50:26 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id x1FFoQdw009385; Fri, 15 Feb 2019 07:50:26 -0800 (PST) (envelope-from sgk) Date: Fri, 15 Feb 2019 07:50:26 -0800 From: Steve Kargl To: Johannes Lundberg Cc: freebsd-arch@freebsd.org Subject: Re: "DRM removal soon" is premature Message-ID: <20190215155026.GA9317@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> User-Agent: Mutt/1.11.2 (2019-01-07) X-Rspamd-Queue-Id: B72166F322 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [1.71 / 15.00]; HAS_REPLYTO(0.00)[sgk@troutmask.apl.washington.edu]; TO_DN_SOME(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_MED(-0.20)[21.76.95.128.list.dnswl.org : 127.0.11.2]; MX_GOOD(-0.01)[cached: troutmask.apl.washington.edu]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:73, ipnet:128.95.0.0/16, country:US]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(0.62)[0.621,0]; NEURAL_HAM_LONG(-0.48)[-0.477,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[washington.edu]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.79)[0.790,0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[]; IP_SCORE(0.09)[ip: (0.17), ipnet: 128.95.0.0/16(0.23), asn: 73(0.10), country: US(-0.07)] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 15:50:31 -0000 On Fri, Feb 15, 2019 at 09:07:08AM +0000, Johannes Lundberg wrote: > > This happens all time for me with virtualbox-kmod as well in current. > Changes to src breaks certain (kmod) ports and there's always a delay > until they are fixed. This is life in -CURRENT. I accept this and don't > go bitching to virtualbox-kmod maintainers about it. Your usage is an > edge case so naturally there will be a longer delay before breakage is > noticed, until we can get automated CI up and running (even so, there > will be a delay). > Was virtualbox-kmod every a part of the FreeBSD base sytem? drm2 was a part of the base system and it was functional until it was unhooked from the build. The issue with the merged PAE vs. non-PAE i386/pmap.h would have been identified prior to it being committed if either drm2 had not been unhooked or if an exp-run over ports was run. I also don't see how this is an edge case. A part of drm2 removal was the creation of a port, so those who don't have the luxury of updating hardware every year can continue to use drm2. If this type of breakage of functionality formerly in base, and the name calling of someone pointing out the breakage, is the new norm, then it is a harbinger of doom for pkg-base. -- Steve From owner-freebsd-arch@freebsd.org Fri Feb 15 17:41:31 2019 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A187F14E2203 for ; Fri, 15 Feb 2019 17:41:31 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC34B73967 for ; Fri, 15 Feb 2019 17:41:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA id uhUEgQC3wMRX3uhUFgRm3s; Fri, 15 Feb 2019 10:41:21 -0700 X-Authority-Analysis: v=2.3 cv=TL87tGta c=1 sm=1 tr=0 a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17 a=IkcTkHD0fZMA:10 a=CFTnQlWoA9kA:10 a=YxBL1-UpAAAA:8 a=6I5d2MoRAAAA:8 a=5MujDi1ExtQV1IlaB0QA:9 a=QEXdDO2ut3YA:10 a=Ia-lj3WSrqcvXOmTRaiG:22 a=IjZwj45LgO3ly-622nXo:22 Received: from [192.168.1.102] (S0106002401cb186f.gv.shawcable.net [70.67.125.17]) by spqr.komquats.com (Postfix) with ESMTPSA id 75EE91DFD; Fri, 15 Feb 2019 09:41:17 -0800 (PST) Date: Fri, 15 Feb 2019 09:41:16 -0800 User-Agent: K-9 Mail for Android In-Reply-To: <20190215155026.GA9317@troutmask.apl.washington.edu> References: <20190214180101.GB67712@troutmask.apl.washington.edu> <20190214182419.GA67872@troutmask.apl.washington.edu> <20190214190244.GA68143@troutmask.apl.washington.edu> <20190214191739.GA68371@troutmask.apl.washington.edu> <20190214225810.kmfxzeuvr7t7gget@smtp.freebsd.org> <20190214233000.GA2752@troutmask.apl.washington.edu> <3b0ba403-ff96-8c94-6d98-40165473d1f3@gmail.com> <20190215155026.GA9317@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: "DRM removal soon" is premature To: sgk@troutmask.apl.washington.edu, Steve Kargl , Johannes Lundberg CC: freebsd-arch@freebsd.org From: Cy Schubert Message-ID: <6531965D-0E8D-479F-8773-F166651C9334@cschubert.com> X-CMAE-Envelope: MS4wfEDNsjx2SL/zoiIBGoAug18K2/cQrktn42cgwO3pXW5Z5v1hqreT5jLYdZ4ORf89EMqYQtWE2MPx9owH+3Y/sQMmpC7gbRxl+SSrzcDIEPzl9uE5YiP2 UiNDfhQ2kgQubPhoP1D8hnPGwk0oKeJebzF9o6itmfo5LJnL6ZI8Zpz8Zdx+sMeC7oEyRMaJUiDThX4Z7EW/jEYs4DlTA7J7d0nBkc3Z39z/79fMi2LGDYOb 0l7v98blVXQ6p7nSCdwp5C0n+aIsPmpYwbMoTfCgXC8= X-Rspamd-Queue-Id: AC34B73967 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-5.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; IP_SCORE(-1.89)[ip: (-4.86), ipnet: 64.59.128.0/20(-2.54), asn: 6327(-1.98), country: CA(-0.09)]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[spqr.komquats.com]; NEURAL_HAM_SHORT(-0.89)[-0.891,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[9.134.59.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA]; MIME_TRACE(0.00)[0:+]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[17.125.67.70.zen.spamhaus.org : 127.0.0.11] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2019 17:41:32 -0000 On February 15, 2019 7:50:26 AM PST, Steve Kargl wrote: >On Fri, Feb 15, 2019 at 09:07:08AM +0000, Johannes Lundberg wrote: >>=20 >> This happens all time for me with virtualbox-kmod as well in current=2E >> Changes to src breaks certain (kmod) ports and there's always a delay >> until they are fixed=2E This is life in -CURRENT=2E I accept this and >don't >> go bitching to virtualbox-kmod maintainers about it=2E Your usage is an >> edge case so naturally there will be a longer delay before breakage >is >> noticed, until we can get automated CI up and running (even so, there >> will be a delay)=2E >>=20 > >Was virtualbox-kmod every a part of the FreeBSD base sytem? > >drm2 was a part of the base system and it was functional >until it was unhooked from the build=2E The issue with the >merged PAE vs=2E non-PAE i386/pmap=2Eh would have been identified >prior to it being committed if either drm2 had not been=20 >unhooked or if an exp-run over ports was run=2E > >I also don't see how this is an edge case=2E A part of drm2 >removal was the creation of a port, so those who don't have >the luxury of updating hardware every year can continue to >use drm2=2E If this type of breakage of functionality formerly=20 >in base, and the name calling of someone pointing out the >breakage, is the new norm, then it is a harbinger of doom for >pkg-base=2E Just to add a data point, I use drm-current on a 13 year old i386 laptop r= unning -current, used as an i386 test platform=2E Keeping it in sync with m= y amd64 platforms=2E --=20 Pardon the typos and autocorrect, small keyboard in use=2E Cheers, Cy Schubert FreeBSD UNIX: Web: http://www=2EFreeBSD=2Eorg The need of the many outweighs the greed of the few=2E