> Major bumps once stuff went into the kernel weren't allowed at all. > You'd need to fork the driver in any case. So we did this once or > twice on drivers in devel trees like mach64. > However upstream first policy should avoid this need. I'd also prefer > to see getparam for new features instead of version checks. The linear > version check sucks.
This is an interesting concept that opens up some ideas for dealing with feature deprecation, etc. Think about opengl's extension mechanism -- features can be exposed through that mechanism without ever providing a guarantee of future availability -- in fact there is no guarantee of any availability outside the current session. Future versions of a GL driver might add or remove extensions as desired, within the constraints of the GL version number advertised. What we could see is something similar for the DRM interface -- a base level of functionality specified by the Major/Minor numbers, but additional extensions that may be advertised according to the whim of the kernel module that the driver can take advantage of if present, but which it must otherwise function correctly without... Extensions that don't work out can be dropped, those that do can be incorporated into the next increment of the minor number, a la GL1.5 Keith ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
