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

[Nathan Whitehorn]

On 07/24/16 08:45, Warner Losh wrote:
> On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn
> <nwhitehorn at 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