[RFC] xserver: use LRMI for real-mode calls (v2)

Dave Airlie airlied at redhat.com
Mon Nov 30 14:27:33 PST 2009


On Mon, 2009-11-30 at 17:09 -0500, Adam Jackson wrote:
> On Fri, 2009-11-27 at 21:54 +0200, Tiago Vignatti wrote:
> 
> >     git://people.freedesktop.org/~vignatti/xserver libx86-take2
> 
>  41 files changed, 314 insertions(+), 27161 deletions(-)
> 
> That just warms my heart.  xf86int10.c is also all of 303 lines now!
> Well done.
> 
> > 1. vm86 code on libx86 is slightly different from the one we current have on
> >   the server.
> > 
> >   I found several implementations on the web (some old kdrive, our current
> >   Xorg, coreboot, libx86, etc) and I'm not sure which is more desireble for
> >   us. For instance, libx86's has support for {Free, Net, Open}BSD and Xorg's
> >   not. On the other hand, we could simply forget forever vm86 backend, given
> >   x86emu encompass it - ajax has hard arguments to simply remove vm86 either.
> 
> We could reasonably add vm86 support for more platforms to libx86, but
> the emulator should be the default.
> 
> > 2. right now lrmi doesn't let us to pass different functions to the x86
> >   emulator.
> > 
> >   If you need specialised functions to handle access to different types of
> >   memory, then you would need to pass them. That's a feature that we had on
> >   the internal int10 code but no driver was using. Given I'm lazy to change
> >   lrmi, so I vote to not bother with this now.
> 
> Yeah, I'm hard pressed to care.
> 
> Assorted notes:
> 
> - pci_device_read_rom() almost certainly does not need the vgaarb lock.
> I suppose it _might_ if it's trying to grab the rom from 0xc0000, but
> that should really be handled internal to libpciaccess if true.

On Linux the kernel shadows the 0xc0000 file and when you use /sys to
access the boot PCI rom it always gives you the 0xc0000 copy.

So yes definitely inside libpciaccess.

libpciaccess should not fall back to 0xc0000 access itself, unless
we are willing to say libpciaccess is only to be used for video cards.

Dave.



More information about the xorg-devel mailing list