Sottek, Matthew J writes: > > >Boy, I haven't really been following this too closely, but surely this > >sort of thing can be resolved with an extension mechanism or api > >versioning? > > An extension mechanism is fine for eventually extending the basic > functionality, but a driver writer should not have to wait for consensus > to add required features to their driver. Currently I don't think we
Right. Therefore I would call for an extendable API with driver private parts. There is a basic API to handle a minimal set required to make a dump fb work. Something that can be supported by almost any chip there is. Then augment this with an 'optinal' part which handles stuff that is beyond the basics but well understood and supported by more than one driver. Above this put a driver private API. Stuff in there may over time be merged into the optional part when things are well understood and we can find a common denominator. > could get very much consensus on anything other than a very basic API > so saying that advanced features can be defined extensions is perhaps > too optimistic. If the advanced features can just remain device > dependent > extensions, at least in the beginning, then we can probably make some > actual progress in getting to a design. > > API versioning is a must no matter what. Right. Egbert. ------------------------------------------------------- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
