Re: KGI IRC Meeting

[Brian S. J. <br...@tu...>]

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