pciaccess clean up

[Adam Jackson]

On Tue, 2008-03-04 at 01:11 -0300, Tiago Vignatti wrote:
> Ian Romanick escreveu:
> > Fair enough.  The question then become one of where to put it.  Should
> > we put in the X server (like it used to be) or in libpciaccess.  I can
> > see arguments for either place.
> 
> We talked today via IRC about this. Given that we don't have kernel 
> drivers for all devices, Ajax suggested that it must be interesting to 
> have a helper application external to X server. Maybe extend the vbetool 
> [0] to support multiple cards. I'll try to dig deeper until the end of 
> this week on this.

What I intended to say was that if we were going to factor out card
setup from the server, we should go all the way with it and do both bus
setup and POST in the same action.  So _if_ you were to do device enable
external to the server, you should do it in vbetool or similar.

But, right now, we don't have POST split out, and it's actually a fair
bit of work to make vbetool multi-card aware.  Not intractable, but more
time than I really want to wait.

As to Ian's question, I think the enable mechanism belongs in
libpciaccess, since I can imagine it being tied to the OS services.  In
Linux, right now, it's just stuffing a '1' into a file in sysfs, so it's
easy to open-code.  But, imagine an OS interface where you get an
exclusive file descriptor for a /dev node, where ioctl() on it is the
only way to enable PCI decode.  It'd require some fair contortion to get
the server to enable a device like that.

- ajax
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x.org/archives/xorg/attachments/20080304/f00a5484/attachment.pgp>