> In article <79of6j$3lhnn@fido.engr.sgi.com> you write:
> >Alan Cox wrote:
> >
> >> > What about a simple example where you set write a bit plane mask into a graphics
> >> > register, then write some data to the framebuffer? You can't have two programs doing
> >> > that at the same time!
> >>
> >> That depends if the registers can be read back and saved.
> >
> >The real question is who/what is responsible for this state management, X or a device
> >driver. I completely fail to see the advantage of having X do it. Oh, well.
>
> I've seen it done both ways but prefer to put more direct register manipulation
> in the device driver. One approach is to keep the driver exceedingly simple,
> e.g., just memory mapping, granting access to the hardware, etc and put
> all other device knowledge in the server. Some people like that partitioning
> because it keeps the amount of driver code very small. Sometimes it helps
> from a development point of view (particularly in the olden days) assuming
> it is easier to develop/debug user-space code rather than kernel space code.
I assume from your e-mail address that you work for SGI.. Do you have any insight as to
what has driven SGI's decision in the past to architect things one way or the other? Has SGI
ever used that device driver partitioning, but placed the remaining device knowledge in a
support library outside of X?
Ben
Please CC: bennyb@ntplx.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/