My 2 cents on a good topic for our upcoming IRC meeting: I think we need to concentrate on creating a firmer definition of what a KGI driver is and is not expected to do.
Not to get too in-depth before the meeting, but to summarise: IMO there are several areas where we have not limited the scope enough. We need to be more minimalist. For example, since all KGI kernel-side drivers must be accompanied by a userspace driver which is specific to the chipset/hardware, KGI drivers should simply provide those peices of information, and kernel facilities, which the userspace driver cannot know/do on its own. This saves a lot of time and effort trying to find standard ways of expressing things like RAM configurations, and gives the driver author more freedom. The only exception to this IMO should be facilities which are easy to provide because they had to be implemented in order to provide the OS with a console/fb system, mainly mode-setting. Other than that, there should be a strict "validate only" policy. Then there are the areas which we have so far not addressed enough: 1) Absolute system stability precautions 2) Absolute inter-process security 3) Graphics driver system pause/resume due to VC-switch and/or system powersave or suspend-to-disk, and 4) handling funny corner cases safely even if it means killing or blocking the app (e.g. monitor swap during running application). -- Brian
