lkml.org 
[lkml]   [1996]   [Jun]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.105 / U:0.804 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site