I observed that kernel-module-control(used for allowing insmod, rmmod within snap) has some influence on uio snap interface. If same application uses both interfaces, then application fails with EPERM error while trying to access uio interface.
If I eliminate the kernel-module-control dependency, then application is able to access /dev/uio0 interface.
For allowing access to device node of custom char driver from snap application, I did following changes.
- Updated char driver implementation to create the device node as /dev/uio0.
- Added uio slot information in gadget snap and added plug in snap application
- Used different snap application to load char driver using kernel-module-control interface and creating the symbolic link file (ln -s /dev/ui0 /dev/test_driver0). system-file interface to allow creation of symbolic link file in /dev directory.
With these changes, snap application is able to access character driver device node.
Another simple alternative method I found is make use of greengrass-support interface.
I have gone through Allowing interfaces to disable device cgroup/udev.
Is it okay to use greengrass-support interface for my requirement?