libpciaccess x86 backend

[Corbin Simpson]

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.
>
> Samuel
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg
>



-- 
Only fools are easily impressed by what is only
barely beyond their reach. ~ Unknown

Corbin Simpson
<MostAwesomeDude at gmail.com>