misc questions about the device&driver arch
scottl at samsco.org
Tue May 30 07:55:32 PDT 2006
william wallace wrote:
> On 5/30/06, Scott Long <scottl at samsco.org> 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.
> 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?
More information about the freebsd-hackers