libpciaccess x86 backend
mostawesomedude at gmail.com
Tue Jan 19 13:26:47 PST 2010
It doesn't seem that exotic to want a PCI layer, and wasn't the entire
point of libpciaccess to keep PCI code out of the Xserver?
On Tue, Jan 19, 2010 at 12:53 PM, Samuel Thibault
<samuel.thibault at ens-lyon.org> wrote:
> Dave Airlie, le Wed 20 Jan 2010 06:42:30 +1000, a écrit :
>> On Mon, Jan 18, 2010 at 12:37 AM, Samuel Thibault
>> <samuel.thibault at ens-lyon.org> wrote:
>> > This adds support on x86 for OSes that do not have a PCI interface, tinkering
>> > with I/O ports, and makes use of it on GNU/Hurd.
>> Now this might be a dumb question but how to hurd drivers interact
>> with the PCI layer, they all just bang on it directly?
> There is no Hurd PCI driver (yet).
> The only PCI code being used is a temporary glue into GNU Mach.
> Yes, an interface between that and userspace should be designed, etc.
> But since it's a temporary glue, it's not really worth doing it right
> now. Still people would like to already try Xorg.
>> It just seems lazy to add a direct to hw code again in userspace when
>> clearly the kernel should be able for it,
> Depends on the kernel. A kernel could very well not deal with PCI at
> all and let userspace agree on using a "PCI server", that could for
> instance use libpciaccess.
>> not that I really mind, I'm just hoping other OSes don't get this
>> lazy, which marking this code as generic x86 might make them.
> I understand your concern. I still believe it is more helpful to provide
> this in the interim than to let yet another barrier from Xorg support
> for exotic kernels.
> xorg mailing list
> xorg at lists.freedesktop.org
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown
<MostAwesomeDude at gmail.com>
More information about the xorg