pci: Export pci functions through procfs and sysfs

[YusufKhan-gamedev]

Aero should add a sysfs and procfs interface for PCI.

[YusufKhan-gamedev]

Maybe add /dev/<vendor id>/<device id> as another (non-standard) interface?

[Andy-Python-Programmer]

What is the use case for these device interfaces? What is the user supposed to do with them? Are they readonly, etc... Elaborate more on the feature request.

[YusufKhan-gamedev]

What is the use case for these device interfaces? What is the user supposed to do with them? Are they readonly, etc... Elaborate more on the feature request.

Full access to all of the functions (that would still be safe) through a fs interface, rw.

[pitust]

Just do standard sysfs for lspci or mini-lspci

[YusufKhan-gamedev]

Just do standard sysfs for lspci or mini-lspci

+1 but a complementary (maybe easier to implement) nonstandard interface would be pleasant, + maybe a (easy to implement) non-standard ioctl interface?

[48cf]

ioctl is for userspace apps to be able to communicate with kernel and drivers running in the kernel, that would make no sense - if you want PCI access write a kernel module

[YusufKhan-gamedev]

ioctl is for userspace apps to be able to communicate with kernel and drivers running in the kernel, that would make no sense - if you want PCI access write a kernel module

Yeah....but why would PCI access be locked in kernel mode? I would understand if it was exclusive to root but not kernel...

afaik in bsd/linux it is modifiable through root with sysfs

[YusufKhan-gamedev]

Just do standard sysfs for lspci or mini-lspci

Im a bit iffy on in the standard sysfs. seems very redundant, All I would want would be /sys/ vendor /device id/<read, write, foo, bar>

[Dennisbonke]

Considering a lot of Linux userland that uses /sys and /proc expect a certain thing there, it makes the most sense to either not do this at all, or mirror Linux for the biggest part, merely adding things aero specific as required or wanted. Standard sysfs implemented on an as needed and as possible basis is IMHO the best way to go, same for procfs.

[YusufKhan-gamedev]

Considering a lot of Linux userland that uses /sys and /proc expect a certain thing there, it makes the most sense to either not do this at all, or mirror Linux for the biggest part, merely adding things aero specific as required or wanted. Standard sysfs implemented on an as needed and as possible basis is IMHO the best way to go, same for procfs.

Yeah, but the (pci) standard is awful imho, i2(/3)c, usb, firewire, is good but the pci proc/sysfs standard is abhorrent(imho UNIX is a curse but thats a separate thing).

[Dennisbonke]

Considering Aero is UNIX like, and likely won't write its own userland (at least not fully like ToaruOS or SerenityOS), the in your eyes abhorrent standard is the one to follow to maximize portability. UNIX being a curse is a yikes for you I'm afraid, because the aforementioned UNIX likeness of Aero. Then again, be the change you want to see, and implement a better API yourself. I'm sure contributions like that are welcomed.

[pitust]

Just do standard sysfs for lspci or mini-lspci

Im a bit iffy on in the standard sysfs. seems very redundant, All I would want would be /sys/ vendor /device id/<read, write, foo, bar>

there is a reason that isn't there, you know - driving pci devices is hard, and you can't just write values into the configuration space. Also, text is not very fun to work with, you would probably want to use ioctls and at that point why are you even using sysfs

[StaticSaga]

Generally, things that use PCI are too performance sensitive even for the overhead of USB, so you won't be able to write a useful userspace driver using a text-based interface.
Userspace drivers for PCI(e) devices, like DPDK for network cards, aren't meant for general purpose usage but only for extremely high performance scenarios (which is not something Aero is currently targetting).

[ghost]

Generally, things that use PCI are too performance sensitive even for the overhead of USB, so you won't be able to write a useful userspace driver using a text-based interface. Userspace drivers for PCI(e) devices, like DPDK for network cards, aren't meant for general purpose usage but only for extremely high performance scenarios (which is not something Aero is currently targetting).

Yes, but if your creating a driver in user space your probably not going to be caring about performance, though yeah a text based interface may not be the best but it is the most straightforward for people learning about UNIX through Aero(a educational OS!).