> > the HW pipeline itself can't be abstracted in this case. > > I've heard that argument before, and I'm glad Jiri didn't drink the koolaide > and instead wrote dpipe.
Perhaps "can't" was the wrong term to use, but I still believe there's an inherent problem with applying the dpipe approach here. dpipe abstraction is meant [And I admit that I'm not that familiar with its fine-grain details, so feel free to correct me] to give an abstract representation of functional things, I.e., bits in the HW pipeline the user might care about and can gain something from sharing information about it - decision-based statistics [such as in Jiri's initial submission] being an immediate candidate for benefiting from such. For the case of debugging you *could* do the same, but at a huge implementation and code-bloat costs - Let's assume user doesn't use 'magic values' for debug gathering, Instead having some HW abstraction it can manipulate intelligibly. What it means is that level of configurability is limited by the complexity of the abstraction, and you have to recall the vast majority of the abstraction would be in-depth about HW-specific bridges and signals the user cares nothing about [with the exception of debug-data collection]. I surely wouldn't want to write a million lines of code just to provide such a detailed abstraction. .
