From: Andreas Beck <becka@rz.uni-duesseldorf.de>
  To  : ggi-develop@eskimo.com
  Date: Thu, 3 Jun 1999 12:54:10 +0200

Re: GGIMesa updates/questions

> > ??? The _driver_ should know about the APIs. That is, the _driver_ should
> > export a set of string describing which APIs the card exports. 
> 
> What for?  Since the "API set" exported by the driver will not ever
> change, it really is just one global driver API and thus there is no 
> point to having the driver care about any of that stuff.

Wrong. Backward compatibility is the idea. If you load a new KGi driver onto
an older LibGGI system, a single ID leads to:

Drivers say: Savage3d - LibGGI: Doesn't know it. => no accel.

The system I proposed will yield:
generic-ioctl     ->  LibGGI knows it. ioctl() accel active.
vendor-s3-generic ->  LibGGI know S3 cards. It can MMIO accel simple stuff
                      common to all S3s.
vendor-s3-savage3d->  LibGGI doesn't know. Tough luck.

This enables us to make better use of our layered driver structure for
card families. We can place the common code in a generic module that
works for the whole family and add specific code in additional libs.

This yields less double code being produced.

> Just have the userspace code map an ident string retrieved from the 
> driver to an interface table or caplist or whatever you are using.

That would require updating the userspace code at installing a new driver.
Look at the tries with acceled XF86fbdev on what that leads to.

I don't see the merit of pulling that information out of the driver, as it
1. isn't much. A few 100 bytes of string data.
2. it hints the driver writers at looking, if they can easily support
fallback family-APIs. (I don't advocate emulating them, though - that
would be a waste of time and space).

> Because there's no point to using it other than to know that the
> driver can map a LibGGI GC, 

No. That's precisely what it was _not_ designed for. It was designed for
telling the external parts (be it LibGGI or whatever) about all APIs it
exports. And these should be multiple , if you want to be reasonably
backward compatible.

A single "driver-id-string" carries no information for older libs on what
the card can do.

That is, you must update the userspace code when installing a new kernel
driver, to get at least some acceleration. 

> which is a bad thing anyway because there's no reasonable way to support 
> API-specific context handling directly in the driver for all possible 
> userspace APIs.  

The idea was to have a reserved space in the GC (say bytes 2048-4095) that
is card-private and will only be touched by the most specific API lib.

> Even the LibGGI GC support should not be hardwired into KGI, IMHO.  
> Contexts are API-specific, not hardware-specific, so it is the API 
> code, not the driver, that should care about them. 

The GC mapping is done for exactly one reason: Having _fast_ communications
for GC parameters to kernelspace. If you run from userspace by hitting the
card accel, this is no issue. But for ioctl-accel, PingPong and friends,
you need to either transfer the whole GC state at each call or have a quick
way to access it from kernelspace.

> > vendor-s3          - this is an S3 board. Load an eventual common accel dirver.
> > vendor-s3-savage3d - it's a savage-3D

> 	Why is this any better than having one ioctl which asks the driver to
> return a unique ident string which then is mapped to all those interfaces in
> userspace? 

Because you have to modify that map every time a new driver pops up.

> It is certainly worse in that it dramatically reduces the
> flexibility of the driver-userspace communications pipe.

I what respect ? The very last string in the list is exactly your unique ID
string.

It's more or less a reasonable extension to what you propose that has the
additional capability to work with older userspace driver without changing a
line of code in them.

> The card should export _one_ global API.  Device drivers should not
> have to care about how they are used, they should have to care about
> abstracting the hardware.  If the hardware doesn't change, the exported 
> API will not change, and thus there is no point in allowing for that 
> change within the structure of the driver itself.

The hardware the driver is for will not change. But there will be hardware
that is more-or less compatible with the existing one.

> If the card exports MMIO areas, the driver-specific target code
> should be aware of that and directly handle the use of those card-specific
> features appropriately.  At the very least, if general-purpose buffer
> management code is to be used, there still needs to be some device-specific
> _userspace library code_ which handles the setup and translation between the
> hardware native interface and other hardware-independent userspace systems.

That _requires_ installing a userspace driver for _ALL_ LibGGI extensions at
driver install time. Else all not-installed extension will crawl.
The multi-layer setup I propose willuse the fallback capabilities and
thus get at least reasonable performance.

CU, ANdy

-- 
= Andreas Beck                    |  Email :  <andreas.beck@ggi-project.org> =