Date: Sun, 24 Jul 2016 09:00:05 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Michal Meloun <mmel@freebsd.org>, Svatopluk Kraus <skra@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> 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 Message-ID: <4c7b76c3-42c3-6039-00dc-9ed08b885315@freebsd.org> In-Reply-To: <CANCZdfq4Yep=dGWUEt4jjnip2O3G4yOxa3jasD8jX5QN-RFSJw@mail.gmail.com> References: <201606051620.u55GKD5S066398@repo.freebsd.org> <b9606755-69cb-2cb0-04d7-6be32e4cb89e@freebsd.org> <578E0B5D.3070105@FreeBSD.org> <e026f6fc-76ed-5dbe-00fc-365b6d7bcf94@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> <CANCZdfq4Yep=dGWUEt4jjnip2O3G4yOxa3jasD8jX5QN-RFSJw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/24/16 08:45, Warner Losh wrote: > On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn > <nwhitehorn@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4c7b76c3-42c3-6039-00dc-9ed08b885315>