On 07/24/16 08:45, Warner Losh wrote:
On Sun, Jul 24, 2016 at 9:32 AM, Nathan Whitehorn
<nwhiteh...@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
_______________________________________________
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
