Can hardware be accessed directly from user space?
At work we have some embedded devices controlled by DOS software. I have been tasked with the responsibility of assessing the use of Linux as a replacement OS for DOS on a next generation of hardware. My research leads me to the conclusion that DOS is simply a totally different type of operating system that allows you to do potentially dangerous things if you want to. From my understanding if you wish to access hardware directly you would have to write a custom driver. What I need to know to satisfy the curiosity of my boss is the following: is it at all possible to access hardware directly from user space??
My guess is no, but I would like to request the opinion of those with knowledge far greater than mine.
linux drivers hardware
add a comment |
At work we have some embedded devices controlled by DOS software. I have been tasked with the responsibility of assessing the use of Linux as a replacement OS for DOS on a next generation of hardware. My research leads me to the conclusion that DOS is simply a totally different type of operating system that allows you to do potentially dangerous things if you want to. From my understanding if you wish to access hardware directly you would have to write a custom driver. What I need to know to satisfy the curiosity of my boss is the following: is it at all possible to access hardware directly from user space??
My guess is no, but I would like to request the opinion of those with knowledge far greater than mine.
linux drivers hardware
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43
add a comment |
At work we have some embedded devices controlled by DOS software. I have been tasked with the responsibility of assessing the use of Linux as a replacement OS for DOS on a next generation of hardware. My research leads me to the conclusion that DOS is simply a totally different type of operating system that allows you to do potentially dangerous things if you want to. From my understanding if you wish to access hardware directly you would have to write a custom driver. What I need to know to satisfy the curiosity of my boss is the following: is it at all possible to access hardware directly from user space??
My guess is no, but I would like to request the opinion of those with knowledge far greater than mine.
linux drivers hardware
At work we have some embedded devices controlled by DOS software. I have been tasked with the responsibility of assessing the use of Linux as a replacement OS for DOS on a next generation of hardware. My research leads me to the conclusion that DOS is simply a totally different type of operating system that allows you to do potentially dangerous things if you want to. From my understanding if you wish to access hardware directly you would have to write a custom driver. What I need to know to satisfy the curiosity of my boss is the following: is it at all possible to access hardware directly from user space??
My guess is no, but I would like to request the opinion of those with knowledge far greater than mine.
linux drivers hardware
linux drivers hardware
edited 3 hours ago
Rui F Ribeiro
41.5k1483140
41.5k1483140
asked Jul 13 '12 at 17:17
mathematician1975mathematician1975
71311239
71311239
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43
add a comment |
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43
add a comment |
2 Answers
2
active
oldest
votes
Your guess is correct. The kernel is the only software that can send hardware requests. That does not only hold true for Linux. Virtually no operating system newer than DOS lets you access hardware directly, because, as you also suspect, it's quite quite dangerous.
However, there is no problem in writing your own driver and plenty of documentation is available. For example, this tutorial at xatlantis seems a recent (that's important!) and good source.
add a comment |
Yes, but it is rarely useful. On 32-bit x86 systems, you can use the ioperm(2)
system call to set up the current process to allow it to perform port I/O directly. I believe this does not work on 64-bit systems. You can also do lseek/read/write
combinations against /dev/port
and I think this likewise is not very portable. See http://tldp.org/HOWTO/IO-Port-Programming-2.html for some more details. Both of these approaches are much slower and less flexible than writing a device driver of course (/dev/port
slowest of all). None of tese userspace mechanisms allow you to handle interrupts or anything like that, of course. If performance is an issue you're going to end up writing a device driver.
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
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: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
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%2funix.stackexchange.com%2fquestions%2f42980%2fcan-hardware-be-accessed-directly-from-user-space%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Your guess is correct. The kernel is the only software that can send hardware requests. That does not only hold true for Linux. Virtually no operating system newer than DOS lets you access hardware directly, because, as you also suspect, it's quite quite dangerous.
However, there is no problem in writing your own driver and plenty of documentation is available. For example, this tutorial at xatlantis seems a recent (that's important!) and good source.
add a comment |
Your guess is correct. The kernel is the only software that can send hardware requests. That does not only hold true for Linux. Virtually no operating system newer than DOS lets you access hardware directly, because, as you also suspect, it's quite quite dangerous.
However, there is no problem in writing your own driver and plenty of documentation is available. For example, this tutorial at xatlantis seems a recent (that's important!) and good source.
add a comment |
Your guess is correct. The kernel is the only software that can send hardware requests. That does not only hold true for Linux. Virtually no operating system newer than DOS lets you access hardware directly, because, as you also suspect, it's quite quite dangerous.
However, there is no problem in writing your own driver and plenty of documentation is available. For example, this tutorial at xatlantis seems a recent (that's important!) and good source.
Your guess is correct. The kernel is the only software that can send hardware requests. That does not only hold true for Linux. Virtually no operating system newer than DOS lets you access hardware directly, because, as you also suspect, it's quite quite dangerous.
However, there is no problem in writing your own driver and plenty of documentation is available. For example, this tutorial at xatlantis seems a recent (that's important!) and good source.
edited Jul 19 '12 at 9:12
cjm
20.7k67173
20.7k67173
answered Jul 13 '12 at 17:36
BananguinBananguin
5,4151340
5,4151340
add a comment |
add a comment |
Yes, but it is rarely useful. On 32-bit x86 systems, you can use the ioperm(2)
system call to set up the current process to allow it to perform port I/O directly. I believe this does not work on 64-bit systems. You can also do lseek/read/write
combinations against /dev/port
and I think this likewise is not very portable. See http://tldp.org/HOWTO/IO-Port-Programming-2.html for some more details. Both of these approaches are much slower and less flexible than writing a device driver of course (/dev/port
slowest of all). None of tese userspace mechanisms allow you to handle interrupts or anything like that, of course. If performance is an issue you're going to end up writing a device driver.
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
add a comment |
Yes, but it is rarely useful. On 32-bit x86 systems, you can use the ioperm(2)
system call to set up the current process to allow it to perform port I/O directly. I believe this does not work on 64-bit systems. You can also do lseek/read/write
combinations against /dev/port
and I think this likewise is not very portable. See http://tldp.org/HOWTO/IO-Port-Programming-2.html for some more details. Both of these approaches are much slower and less flexible than writing a device driver of course (/dev/port
slowest of all). None of tese userspace mechanisms allow you to handle interrupts or anything like that, of course. If performance is an issue you're going to end up writing a device driver.
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
add a comment |
Yes, but it is rarely useful. On 32-bit x86 systems, you can use the ioperm(2)
system call to set up the current process to allow it to perform port I/O directly. I believe this does not work on 64-bit systems. You can also do lseek/read/write
combinations against /dev/port
and I think this likewise is not very portable. See http://tldp.org/HOWTO/IO-Port-Programming-2.html for some more details. Both of these approaches are much slower and less flexible than writing a device driver of course (/dev/port
slowest of all). None of tese userspace mechanisms allow you to handle interrupts or anything like that, of course. If performance is an issue you're going to end up writing a device driver.
Yes, but it is rarely useful. On 32-bit x86 systems, you can use the ioperm(2)
system call to set up the current process to allow it to perform port I/O directly. I believe this does not work on 64-bit systems. You can also do lseek/read/write
combinations against /dev/port
and I think this likewise is not very portable. See http://tldp.org/HOWTO/IO-Port-Programming-2.html for some more details. Both of these approaches are much slower and less flexible than writing a device driver of course (/dev/port
slowest of all). None of tese userspace mechanisms allow you to handle interrupts or anything like that, of course. If performance is an issue you're going to end up writing a device driver.
answered Jul 13 '12 at 23:29
James YoungmanJames Youngman
765315
765315
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
add a comment |
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
But work with interrupts and DMA is still impossible in userspace (AFAIK) So device access from userspace is limited to communicate via ports or device mapped memory.
– Netch
Jul 15 '12 at 10:33
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
Yes, which is why I mentioned that in my answer.
– James Youngman
Jul 15 '12 at 22:18
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- 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%2funix.stackexchange.com%2fquestions%2f42980%2fcan-hardware-be-accessed-directly-from-user-space%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
How are the devices accessed from the OS? E.g. are they PCI cards?
– daniel kullmann
Jul 13 '12 at 18:16
I believe so yes. Most hardware is wired into the board directly (like serial ports and ethernet adaptor). There are devices attached also - I am a simple desktop application developer so my in depth knowledge of hardware is very limited. Hence my asking here.
– mathematician1975
Jul 13 '12 at 18:21
If you are not using specialized hardware and are only looking to get serial-ports and ethernet working, you probably don't need to access the hardware directly ...
– Bananguin
Jul 13 '12 at 18:38
This was my thought to be honest. However, I think because the old code uses stuff like hardware interrupts to access incoming TCP and serial transmissions my boss wants the same functionality. It's probably a real-time issue. I personally cant see the problem with using things like poll() or select() to get data.
– mathematician1975
Jul 13 '12 at 18:43