does linsysfs support mmap on pci resources (e.g. pci device's registers etc.)

[leon zadorin]

On Wed, Oct 1, 2014 at 7:12 PM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> You choice of the list to ask the question is weird.  I added hackers@
> as more suitable ML.

I see,

Sure thing about adding the post to another list -- sorry about doing
the original post to this list (freebsd-emulation).

I had read the lists's description:
"A list for the Development of Emulators of other operating systems
and enviroments for FreeBSD. These include: BSDI, Linux, and some
microsoft products.
" https://lists.freebsd.org/mailman/listinfo/freebsd-emulation

and given that my post was essentially about whether FreeBSD emulated
linux OS "sysfs" feature(s) I thought it might be of some relevance to
the list... but being a noob to the list I have possibly not made the
best choice :)

> On Wed, Oct 01, 2014 at 03:44:48PM +1000, leon zadorin wrote:
>> Hello everyone,
>> Sorry if this is a bit of a noob question -- I'm just starting on this
>> topic... does FreeBSD's emulation of sysfs (from linux world) support
>> "mmap" on pci resources?
>>
>> Something similar to the following in the linux environment:
>>
>> fd = open("/sys/devices/pci0001\:00/0001\:00\:07.0/resource0", O_RDWR | O_SYNC);
>> ptr = mmap(0, 4096, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
>> printf("PCI BAR0 0x0000 = 0x%4x\n",  *((unsigned short *) ptr);
>>
>> (above taken from
>> http://billfarrow.blogspot.com.au/2010/09/userspace-access-to-pci-memory.html)
[...]
> AFAIK, there is no facilities in FreeBSD kernel which allow you to get
> the configuration registers or memory BARs mmapped into the userspace.
> The linsysfs is out of question for this sort of hacks. The native
> FreeBSD' /dev/pci does not support mmaping either.
>
> It should be not too hard to extend the /dev/pci to do what you described.
> Start looking at the sys/dev/pci/pci_user.c
>
> PCIe configuration window is active, so you could access it by hand by
> mmapping /dev/mem. Also, the window is mapped into KVA, so you could
> access it by /dev/kmem as well. /dev/mem would be easier, I think,
> because it needs the physical address, which can be learned from ACPI
> MCFG much easier than the value of the static symbol pcie_base.

I see -- thanks for the pointers! I shall consider my options :)