You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pci: Export pci functions through procfs and sysfs #58
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.
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.
+1 but a complementary (maybe easier to implement) nonstandard interface would be pleasant, + maybe a (easy to implement) non-standard ioctl interface?
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
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
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.
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).
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.
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
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).
Activity
YusufKhan-gamedev commentedon Mar 14, 2022
Maybe add
/dev/<vendor id>/<device id>as another (non-standard) interface?Andy-Python-Programmer commentedon Mar 14, 2022
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 commentedon Mar 18, 2022
Full access to all of the functions (that would still be safe) through a fs interface, rw.
pitust commentedon Mar 18, 2022
Just do standard sysfs for lspci or mini-lspci
YusufKhan-gamedev commentedon Mar 19, 2022
+1 but a complementary (maybe easier to implement) nonstandard interface would be pleasant, + maybe a (easy to implement) non-standard ioctl interface?
48cf commentedon Mar 19, 2022
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 commentedon Mar 19, 2022
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 commentedon Mar 20, 2022
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 commentedon Mar 20, 2022
Considering a lot of Linux userland that uses
/sysand/procexpect 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 commentedon Mar 20, 2022
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 commentedon Mar 20, 2022
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 commentedon Mar 20, 2022
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 commentedon Mar 20, 2022
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).