Is there any value in integrating this in kernel-space vs user-space? This increases the maintenance burden of the kernel for something only a tiny minority would ever use.
adrian_b•2mo ago
Many decades ago I have written some MS-DOS GPIB device drivers.
In MS-DOS there was no memory protection or I/O port protection, so the separation between kernel and user was not a concern when writing a device driver.
The implementation of the communication protocols of the various GPIB instruments is something that should be done by a library in user space, and this will be the bulk of the code required by a GPIB application.
There are however a few functions that must access protected resources, e.g. I/O ports on the GPIB interface card, DMA channels and interrupt handling, and these protected resources will vary between interface cards.
Those functions must be contained in a kernel-mode device driver, but it should be relatively small and it would contain the code that is specific to the different kinds of GPIB interface cards, but which is the same for any kind of GPIB instrument that could be attached to the computer (while the user-space library should not depend on the GPIB interface card, but it should contain all code specific to various classes of GPIB instruments).
It would possible to have a GPIB device driver working in non-privileged user mode, but this is something that Linux unfortunately does not implement. For such a non-privileged device driver, the kernel would have to map with allowed access any memory-mapped I/O resources from the interface card and it would also have to create an I/O port permission bit map allowing direct access to the I/O ports of the interface card.
Then the GPIB application would link the library that implements the GPIB communication protocols and it would use IPC to communicate with the user-mode GPIB device driver, which could access the GPIB interface card.
Nextgrid•2mo ago
adrian_b•2mo ago
In MS-DOS there was no memory protection or I/O port protection, so the separation between kernel and user was not a concern when writing a device driver.
The implementation of the communication protocols of the various GPIB instruments is something that should be done by a library in user space, and this will be the bulk of the code required by a GPIB application.
There are however a few functions that must access protected resources, e.g. I/O ports on the GPIB interface card, DMA channels and interrupt handling, and these protected resources will vary between interface cards.
Those functions must be contained in a kernel-mode device driver, but it should be relatively small and it would contain the code that is specific to the different kinds of GPIB interface cards, but which is the same for any kind of GPIB instrument that could be attached to the computer (while the user-space library should not depend on the GPIB interface card, but it should contain all code specific to various classes of GPIB instruments).
It would possible to have a GPIB device driver working in non-privileged user mode, but this is something that Linux unfortunately does not implement. For such a non-privileged device driver, the kernel would have to map with allowed access any memory-mapped I/O resources from the interface card and it would also have to create an I/O port permission bit map allowing direct access to the I/O ports of the interface card.
Then the GPIB application would link the library that implements the GPIB communication protocols and it would use IPC to communicate with the user-mode GPIB device driver, which could access the GPIB interface card.