From owner-svn-src-head@freebsd.org Sun Jul 24 16:00:13 2016 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73D84BA3116; Sun, 24 Jul 2016 16:00:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5B0FF160E; Sun, 24 Jul 2016 16:00:13 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id u6OG05pM009715 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 24 Jul 2016 09:00:06 -0700 Subject: Re: svn commit: r301453 - in head/sys: arm/arm arm64/arm64 dev/fdt dev/gpio dev/iicbus dev/ofw dev/pci dev/vnic kern mips/mips sys To: Warner Losh References: <201606051620.u55GKD5S066398@repo.freebsd.org> <578E0B5D.3070105@FreeBSD.org> <578F6075.7010500@FreeBSD.org> <05a80ac6-4285-ec9d-36e9-2f92c609f746@freebsd.org> <57907B0F.9070204@FreeBSD.org> <9d2a224c-b787-2875-5984-a7a2354e8695@freebsd.org> <57934ABD.6010807@FreeBSD.org> <4e7a3e8f-cc21-f5f2-e3e0-4dbd554a4cd0@freebsd.org> <5794720F.4050303@FreeBSD.org> <8bfd8668-bc49-e109-e610-b5cd470be3ec@freebsd.org> Cc: Michal Meloun , Svatopluk Kraus , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" From: Nathan Whitehorn Message-ID: <4c7b76c3-42c3-6039-00dc-9ed08b885315@freebsd.org> Date: Sun, 24 Jul 2016 09:00:05 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVYy0vQj3PauRi/Yx7jlImhjDoBYJDD49v0ysoficYSOsSQtJHVIvLmpiCwAkcaYHYvJqDNYVPHAT+iegMjkE4YHwko5srxhqSM= X-Sonic-ID: C;4v3xr7dR5hG/9ptMTlz00w== M;zORIsLdR5hG/9ptMTlz00w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 16:00:13 -0000 On 07/24/16 08:45, Warner Losh wrote: > On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn > wrote: >> This will make this much harder to untangle, unfortunately, and probably >> means we are stuck with this as a rump API in stable/11. > The time to have had this discussion was 9 months ago when it first started > to appear in the tree and on differential and on the mailing lists. > > I'm also not convinced that 'planes' would be the right way to solve the > interrupt issues. There's been talk about it for a long time, but no action. > The relationships in FDT are DAGs, not trees, and newbus is inherently > tree-based. > > Warner > I at least had never seen this code until it appeared in the tree and went through a phabricator review during code slush in which no one approved it. The general discussion of INTRNG 9 months ago was great, and I wrote some of the code. It is a big step forward. This particular code, however, is not consistent with the understanding of what INTRNG would be that I got from that discussion. The actual discussion on mailing lists seems to consist only of this cryptic email on an ARM list (https://lists.freebsd.org/pipermail/freebsd-arm/2016-June/013976.html) with no meaningful content right before the commit and some phabricator reviews that no one signed off on, that do not include all the relevant maintainers, and that end in one case with open questions followed by a commit. Since this fundamentally affects parts of kern/ and newbus, this needed to be on freebsd-arch for a month at the *very* least and to have positive approval. Given how this was handled and where we are in the release cycle, I don't know what the right course of action is; I see no good outcomes at this point. The core problem is that the code in this commit series duplicates an existing architecture that solves all the problems it purports, but can't ever be portable to other platforms because of its dependency model. As such, it will either (a) bitrot or (b) sit in the tree as a permanent, inflexible, ARM-only adjunct to the systems used on other platforms, filling kern and dev/ofw with progressively more #ifdef. We worked very hard to *remove* an API very similar from this on MIPS in the initial parts of INTRNG because it crippled the flexibility of the system. Having it appear again, under the radar, during code slush with no meaningful review and the author unreachable right before a major release is extremely disappointing. -Nathan