Messages in this thread |  | | Date | Thu, 6 Jun 1996 01:00:58 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: SVGA kernel chipset drivers. |
| |
Date: Wed, 5 Jun 1996 21:38:35 -0700 (PDT) From: "Jon M. Taylor" <taylorj@gaia.ecs.csus.edu>
First, it is GGI, not CGI. Second, why must this be set in stone? If things can change as much as they have in the /proc filesystem, a precedent is there for this sort of thing. Besides, there are undoubtedly ways of either ensuring complete backwards compatibility (i.e., IOCTLs only get added, never removed or modified) or implementing some srt of versioning scheme to ensure that older apps always use the IOCTL set they were compiled to use. I'm sure that there are other solutions as well.
True, you can always add new ioctl's. However, this exposes the fallacy that says that GGI will avoid the requirement of new X servers to support new fancy accelerated boards. If each new accelerated board that has some new accleration feature will require new ioctl()'s, then we will need to compile a new X server to take advantage of the (constantly changing) GGI API. Otherwise, the old GGI X server, since it didn't have the old API calls, won't be able to take advantage of the new accelerated functions.
Hence, to gain full functionality of a new accelerated board, *two* things have to happen. (1) we need to have a new Linux driver written, and (2) we need a new X server that can take advantage of the new GGI ioctl's. Contrast this with the existing method, where we just need (1) a new X server that takes advantage of the features of the new board.
> Finally, please remember that in the grand scheme of things GCI will > double the amount of work required; when a vendor releases a new card, > someone will have to write a GCI Linux kernel module, and XFree86 will > have to put support into their servers directly. After all, remeber > that XFree86 runs on a large number of OS's, not just Linux, and so > regardless of what we do, XFree86 will still have to do all of this > work.
Since both codebases are free, why duplicate the work? Either they develop it first and we use their code, or the reverse.
You're right that it won't be exactly double, however, there will be some amount of new work required, if nothing else to confirm to the differing interfaces between the internals of the XFree6 server and the GGI API.
I don't doubt that there are advantages in putting parts of the video board management inside the kernel. However, there are costs in doing so, and people should neither try to trivialize the cost nor overemphasize the benefit.
- Ted
|  |