R7.1 roadmap, and additional goals

[Philip Prindeville]

Luc Verhaegen wrote:

>It seems that the fact that the string via appears everywhere is the 
>reason why my abstraction is deemed bad. Most people think it's bad 
>to not prepend XXX to global functions and structs in drivers, but it's 
>nothing sed can't handle.
>  
>

Ok, so if it's trivial and it will give people one less reason not to
use it,
then why not do it?

>Then there's the fact that it's not poured into modules yet. But what 
>use is the tiny bit of loader work needed at this point, when there's no 
>second driver making use of this yet. Because that should be the 
>criterium for modularity. The last thing we need is more of the "ati 
>uses it, let's push our lack of abstraction into xfree86/i2c/" kind of 
>modularisation.
>  
>

Well, again, unless *you* change a second driver to make use of it
(and not being a primary contributor of any other drivers, that might
be a hard row to hoe)... On the other hand, adding the loader fluff
to facilitate this happening just might make the possibility so enticing
that other people won't be able to resist... And that's a good thing.

You're arguing a chicken-and-egg problem: there's no second driver
to justify adding the loader fluff... but because the trivial loader
fluff is
missing, no one has bothered to add support for it to a second driver...

Can't comment on the ATI reference: I'm not familiar enough with what
you're talking about.

>Over complicated? Compared to what's needed for TMDS, sure. But TV 
>encoders are a whole different ballgame, yet they still need to fit into 
>the same abstraction. In my view it still lacks a few things, but what's 
>mainly holding me back is ENOHW.
>  
>

I have to concur: better to have a single abstraction even if it's a bit
top-heavy,
than to have a bunch of redundant modules, interfaces, and lines of code...

-Philip

>Luc Verhaegen.
>  
>