0

This article states:

A user space C/C++ program must have been granted access to the /dev/ion device before it can allocate memory from ION. A call to open("/dev/ion", O_RDONLY) returns a file descriptor as a handle representing an ION client. Yes, one can allocate writable memory with an O_RDONLY open. There can be no more than one client per user process.

However, what is unclear to me is if there there can be only one file descriptor to /dev/ion per user process. I mean, "there can be no more than one client per user process" may not necessarily mean "there can be no more than one FD to /dev/ion per user process". For example, it could be that there is only one ION client per process, but that opening multiple /dev/ion FDs just increments an internal ION client reference count, meaning that these multiple FDs all refer to the same ION client.

So, is calling open() multiple times OK?

This is important, because I have multiple code fragments here in a project, and all of them try to open /dev/ion by themselves. If this is okay to do, then I leave them as they are, otherwise I have to refactor them to use one global /dev/ion FD.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
dv_
  • 1,247
  • 10
  • 13
  • It's not presently clear to me, and I'm having trouble finding a primary documentation source, but my first inclination would indeed be to interpret a restriction to one client per process to mean no more than one FD open on the device per process. – John Bollinger Nov 21 '18 at 14:19
  • I wrote a quick test, and it seems that I can indeed open multiple file descriptors. This is an i.MX8M device though, so I am not 100% sure if this isn't the result of modifications from NXP, or perhaps undefined behavior. – dv_ Nov 21 '18 at 20:29
  • "There can be no more than one client per user process" does not necessarily mean that attempts to create additional clients will fail. It could instead mean that one process using multiple clients causes or risks misbehavior. – John Bollinger Nov 21 '18 at 21:09
  • Yeah, that's the problem - this case is poorly defined. Furthermore, newest versions of the ion allocator in the kernel do not even have the ion client anymore, so this whole point is probably moot. For now, I'll have to stick to version/platform specific behavior, like that on the i.MX8. – dv_ Nov 22 '18 at 09:18

0 Answers0