Opening more than one file descriptor to /dev/ion
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.
android c linux ion edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
add a comment |
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.
android c linux ion edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
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 9:18
add a comment |
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.
android c linux ion edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
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.
android c linux ion android c linux ion edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
edited Nov 21 '18 at 14:12
John Bollinger
83.8k74279
83.8k74279
asked Nov 21 '18 at 14:01
dv_dv_
867612
asked Nov 21 '18 at 14:01
dv_dv_
867612
asked Nov 21 '18 at 14:01
dv_dv_
867612
867612
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 9:18
add a comment |
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 9:18
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
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
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
"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 9:18
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 9:18
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413773%2fopening-more-than-one-file-descriptor-to-dev-ion%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53413773%2fopening-more-than-one-file-descriptor-to-dev-ion%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
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 9:18