Is it useful to support user level drivers
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 3 lines
There is no such thing as a "user mode" interrupt service routine. There never was one, and there will never be one on any machine that fetches instructions from memory for execution. [...]
If memory does not deceive me, SunLab Spring processed interrupts in user space. I do not remember for sure, but I think QNX did, too. User mode interrupt handlers are perfectly doable, provided that the hardware allows to mask interrupts selectively.
Large part of the post that I quoted was spent on spitting in the general direction of clueless programmers; indeed, I observe that perhaps 90% of requests for user mode interrupt processing come from the same people who would like to write Linux kernel mode code in C++ (total retards, in other words).
It does not mean, however, that there are not justified cases for user-mode interrupt handlers, especially outside of Linux. Some OSes are even written in C++ and Java, and run just fine on a machine that fetches instructions from memory.
-- Pete
Quoted 4 lines · Pete Zaitcev
If memory does not deceive me, SunLab Spring processed interrupts in user space. I do not remember for sure, but I think QNX did, too. User mode interrupt handlers are perfectly doable, provided that the hardware allows to mask interrupts selectively.
SGI's IRIX does it too, for graphics card interrupts like "VBLANK" and "rendering pipeline FIFO not full anymore".
Later,
David S. Miller
[email protected]
Quoted 9 lines · Pete Zaitcev
Quoted 3 lines
There is no such thing as a "user mode" interrupt service routine. There never was one, and there will never be one on any machine that fetches instructions from memory for execution. [...]
If memory does not deceive me, SunLab Spring processed interrupts in user space. I do not remember for sure, but I think QNX did, too. User mode interrupt handlers are perfectly doable, provided that the hardware allows to mask interrupts selectively.
QNX does not have any difference between user-space and kernel space. It's not paged-virtual. It's just one big sheet of address space with no memory protection (everything is shared). All procedures to be executed are known at compile time.
Therefore, any piece of code can do anything it wants including handling hardware directly. In fact, that's what QNX was designed for.
Quoted 6 lines
Large part of the post that I quoted was spent on spitting in the general direction of clueless programmers; indeed, I observe that perhaps 90% of requests for user mode interrupt processing come from the same people who would like to write Linux kernel mode code in C++ (total retards, in other words).
I think I said (or implied) that too.
Quoted 2 lines
It does not mean, however, that there are not justified cases for user-mode interrupt handlers, especially outside of Linux.
Not if that memory can get swapped or paged out .
Quoted 3 lines
Some OSes are even written in C++ and Java, and run just fine on a machine that fetches instructions from memory.
Then you are stretching the meaning of "OS" just a bit. It's true that I can make an Operating System entirely in interpreted BASIC. However, it is really only a "Command Processor" even though it can have multiple "connections" requesting commands to be processed.
Quoted 2 lines
-- Pete
-
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
Quoted 5 lines · Richard B. Johnson
QNX does not have any difference between user-space and kernel space. It's not paged-virtual. It's just one big sheet of address space with no memory protection (everything is shared). All procedures to be executed are known at compile time.
That's completely, utterly untrue.
QNX does indeed sport paged-virtual memory with memory protection; (although QNX4 does not support swap).
User-mode interrupts are standard procedure; the deadlock problems Alan has mentioned do not apply, since any running process is always resident in memory.
Shared regions have to be explicitly created; access is *not* open to anybody.
Nothing has to be known at "compile time"; QNX is a full-featured OS with dynamic loading.
Quoted 2 lines
Therefore, any piece of code can do anything it wants including handling hardware directly.
Again not true; only privileged processes can enter kernel mode to execute port I/O instructions directly.
cheers
Anders
Signature · 2 lines
"In theory there is no difference between theory and practice. In practice there is." - Yogi Berra
Quoted 10 lines · Anders Larsen
Quoted 5 lines · Richard B. Johnson
QNX does not have any difference between user-space and kernel space. It's not paged-virtual. It's just one big sheet of address space with no memory protection (everything is shared). All procedures to be executed are known at compile time.
That's completely, utterly untrue.
QNX does indeed sport paged-virtual memory with memory protection; (although QNX4 does not support swap).
Then QNX is not the QNX that I have used.
Quoted 10 lines
User-mode interrupts are standard procedure; the deadlock problems Alan has mentioned do not apply, since any running process is always resident in memory.
Shared regions have to be explicitly created; access is *not* open to anybody.Nothing has to be known at "compile time"; QNX is a full-featured OS with dynamic loading.
The QNX that I have used, advertised as QNX, and been around since 32-bit ix86 was available, is EXACTLY as I stated.
Quoted 6 lines
Quoted 2 lines
Therefore, any piece of code can do anything it wants including handling hardware directly.
Again not true; only privileged processes can enter kernel mode to execute port I/O instructions directly.
The QNX that I have used, again is EXACTLY as stated.
Quoted 2 lines
cheers
Anders
If you have used a different QNX, then QNX has either changed radically, or is a different company/QNX than what I used. And, I had a lot of good experiences with it since standard I/O was provided, as was boot, but it was an open book otherwise in which you were not prevented from doing anything you wanted to do, at any instant you wanted to do it.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips).
"Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk.
Quoted 10 lines · Richard B. Johnson
Quoted 7 lines · Anders Larsen
Quoted 5 lines · Richard B. Johnson
QNX does not have any difference between user-space and kernel space. It's not paged-virtual. It's just one big sheet of address space with no memory protection (everything is shared). All procedures to be executed are known at compile time.
Quoted 5 lines
Quoted 3 lines
That's completely, utterly untrue.
QNX does indeed sport paged-virtual memory with memory protection; (although QNX4 does not support swap).Then QNX is not the QNX that I have used.
Or you haven't used it recently (= within the past 10 years)
Quoted 6 lines
Quoted 6 lines
User-mode interrupts are standard procedure; the deadlock problems Alan has mentioned do not apply, since any running process is always resident in memory.
Shared regions have to be explicitly created; access is *not* open to anybody.
Quoted 6 lines
Quoted 3 lines
Nothing has to be known at "compile time"; QNX is a full-featured OS with dynamic loading.
The QNX that I have used, advertised as QNX, and been around since 32-bit ix86 was available, is EXACTLY as I stated.
Dynamic loading of executables has been in QNX for as long as I know it (fifteen years).
With the appearance of QNX version 4 some ten years ago came 32-bit address space, full memory management/protection etc.
Quoted 7 lines
Quoted 5 lines
Quoted 2 lines
Therefore, any piece of code can do anything it wants including handling hardware directly.
Again not true; only privileged processes can enter kernel mode to execute port I/O instructions directly.
The QNX that I have used, again is EXACTLY as stated.
It must have been an early QNX version 2, then.
QNX 2 did not have any memory protection.
Quoted 6 lines
If you have used a different QNX, then QNX has either changed radically, or is a different company/QNX than what I used. And, I had a lot of good experiences with it since standard I/O was provided, as was boot, but it was an open book otherwise in which you were not prevented from doing anything you wanted to do, at any instant you wanted to do it.
Of course QNX has changes radically over the decades (it's been around for some twenty years now); what I frowned at was that you made your statements as if they would apply to the *current* state of affairs, which they certainly do not.
cheers
Anders
Signature · 2 lines
"In theory there is no difference between theory and practice. In practice there is." - Yogi Berra
Quoted 9 lines · David S. Miller
Quoted 4 lines · Pete Zaitcev
If memory does not deceive me, SunLab Spring processed interrupts in user space. I do not remember for sure, but I think QNX did, too. User mode interrupt handlers are perfectly doable, provided that the hardware allows to mask interrupts selectively.
SGI's IRIX does it too, for graphics card interrupts like "VBLANK" and "rendering pipeline FIFO not full anymore".
Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.
--macko
SGI Graphics Kernel Engineer 1994-1999
Quoted 1 line · Mike Mackovitch
Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.
What the heck is ULI then? I've actually read the assembly code for this back when I did my SGI internship.
Later,
David S. Miller
[email protected]
Quoted 6 lines · David S. Miller
Quoted 1 line · Mike Mackovitch
Sorry, but SGI's IRIX does NOT handle graphics interrupts in user space.
What the heck is ULI then? I've actually read the assembly code for this back when I did my SGI internship.
If my memory serves me correctly, I believe ULI was some hacked up "user-level interrupt" feature. I have no idea who (if anyone) used it, but it definitely wasn't used by SGI's graphics drivers.
--macko
Quoted 8 lines · Mike Mackovitch
Quoted 2 lines · David S. Miller
What the heck is ULI then? I've actually read the assembly code for this back when I did my SGI internship.
If my memory serves me correctly, I believe ULI was some hacked up "user-level interrupt" feature. I have no idea who (if anyone) used it, but it definitely wasn't used by SGI's graphics drivers.
Strange, because taking veritcal retrace interrupts directly in userspace was the first thing that came to my mind when I saw what ULI was doing.
When IRIX optimizes something to the extreme, it is either for big-iron or graphics performance, very few exceptions exist :-)
Later,
David S. Miller
[email protected]