william wallace wrote:
On 5/30/06, Scott Long <[EMAIL PROTECTED]> wrote:
M. Warner Losh wrote:
> : THIRD
> : Because the PCIE configure space is 4k long ,shall we change the
> : #define PCI_REGMAX 255
> : to facilitate the PCI express config R/W?
>
> Maybe. Lemme investigate because PCIe changes this from a well known
> constant for all pci busses, to a variable one...
>
> Warner
When I added PCIe extended config support, I never took into
consderation the userland access point of view. Changing this
definition to 4096 might Just Work, and it might Not Work. Dunno.
In the 18 months since I implemented it, no other person has asked
about userland access. Other than the silly case of people trying
to write device drivers in PERL, I'm not sure how much value it
gives compared to the stability and security risk it imposes.
Scott
I have to clarify my intentions that i am not TRYing to do a userland
PCI express driver . I just want to make a interesting branch whitch
can do pci express native Hot plug and hot remove ,with Mr Losh and
other gentlemen's help ,i am making progress ,and now a loadable
module is finishing .
I have borrowed many Ideas from Linux ,but several fatal difficulties
paused me ,with the PCI_REGMAX included.
wish to hear from u :) thank u!
The PCI_REGMAX definition is not used by the extended configuration
space code. However, this code only exists on i386 right now. I
haven't gotten around to implementing it on amd64 yet. Implementing
it there is not just a trivial change of the defintion. Some platform
specific memory map tricks need to be done. It would be possible to
port the i386 code wholesale, but that code is not terribly efficient
on the amd64 platform.
So, what problem are you running into?
Scott
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
