Interrupt-Driven Linux

J

James Adrian

Guest
Is there a Linux distribution that works on PCs and OS X that is purely interrupt driven and does not use supervisory loops?

Thank you for your help.

Jim Adrian
 


Welcome, Jim!

I think your question is (way) over my head... but let me ask, "Are you talking about virtual machines?" Sorry, I'm not sure what it is that you're asking.
 
Any operating system starts with a reset program that sets the state of all the hardware. At this point, it has the option of going into an infinite loop that does nothing but that can be interrupted by hardware interrupts. When an interrupt is received by the processor it goes to the address of the first instruction of an interrupt program. Each hardware interrupt is assigned such an address by the hardware of the processor. If all programs get started only in this way, the operating system is said to be purely interrupt driven.

If instead of an interruptible infinite loop, the reset program is followed by a supervisory loop that checks everything of interest without waiting for any hardware interrupts, the operating system is said not to be purely interrupt driven.

Jim Adrian
 
Last edited:
Okay, then I guess you mean "Apple hardware," and not "OS X"... right? I took your original post to ask, "Is there a Linux operating system that works on an Apple operating system... etc?" That's why I asked if you were referring to virtual machines.

Again, I don't think I can give you an intelligent response, much less an answer (although my gut feeling is that the answer is no). From what I've heard it is difficult enough just to get Linux to run on a Mac, at least partly due to their different implementation of EFI.

But there are a lot of smart people on here, so I hope that someone will be able to offer you a knowledgeable answer.

Cheers!
 
I'm not sure what you're asking about though.

TLDR Pretty much all of the modern operating systems are interrupt driven because of the efficiency, compared to polling. Applications don't see interrupts, since they happen in the kernel, and not in userspace. Note that signals (such as SIGINT when you press Ctrl+C in Bourne shell) aren't interrupts.

First of all, Apple moved to Intel processors completely in 2009 with "Snow Leopard", and the transition itself started in 2005. So, there are no differences between "PC" and "OSX" in terms of instruction sets (both use i386/amd64), unless your "PC" is ARM-based (or SPARC, or DEC Alpha, or... you get the point). Linux works on pretty much everything (except some very old machines with 80286 and lower and VAX probably though porting efforts were made). Running Linux on Apple hardware is not super-easy though, especially on a MacBook, some work with drivers will be needed probably. Fedora and Ubuntu are known to work on Macs.

Secondly, a short explanation of the startup process:
1. BIOS learns the platform and then executes the boot code from the boot device.
2. Boot loader loads the kernel into memory.
3. The kernel decompresses itself, sets up system functions and calls start_kernel(), more on that later.
4. The init system runs scripts and/or configuration files and starts daemons.
5. If present, a display manager loads a desktop environment.

Interrupts are handled by the kernel. During start_kernel() system call interruption handling, memory configuration, init and the idle task are being set up and started. In this part, pretty much all of the distributions, if they are Linux-based, are essentially the same (Linux is a kernel, as you know).

What supervisory loop is I couldn't find. I've never really heard about it.
 
A supervisory loop is just a continual polling by the operating system. Maybe the term isn't used much any more.

All of the actions needed to retrieve programs from the hard disk drive and other storage to achieve a state whereby the next move is up to the user or the environment is included in what I have been calling the reset program.

If the system does nothing after it has been made ready to serve the user or the environment outside of the computer, and services are performed only in response to hardware interrupts from peripheral devices, the operating system is purely interrupt driven. A once-per-second interrupt from a cock, or a press of a key on a keyboard would be examples of hardware interrupts.

The reset program is complicated not only by the need to retrieve programs from storage, but also by the need to check for hardware options that may not exist the same way in all computers using the operating system.

In any case, there comes a time when the computer waits without polling.

Depending on a number of factors, some interrupt input signals may be temporarily disabled. If the system is running a program that controls a robot arm that is pouring coffee, that program may be written to disallow input from a clock tick for a while.

There seem to be real-time versions of Linux. I don't know whether they are purely interrupt driven or just permit some programs to perform in that way. I would provide a link, but I think they are disallowed by the forum. My email address was rejected in my first post above.

Jim Adrian
 
James Adrian said:
Is there a Linux distribution that works on PCs and OS X that is purely interrupt driven and does not use supervisory loops?

Thank you for your help.

Jim Adrian
Click to expand...
Since all "Linux" distributions use the Linux kernel, I would assume that they all operate the same. The only exception might be some difference between the "Linux" kernel, vs the "Hurd" kernel. This is a little beyond my expertise.
 
James Adrian said:
I would provide a link, but I think they are disallowed by the forum. My email address was rejected in my first post above.
Click to expand...

I don't know about the email issue, but after you get a few "likes" then you will be able to post URL's. It is an anti-spammer device that works pretty well. I gave you a couple of likes above to get you started.

Cheers!
 
James Adrian said:
A supervisory loop is just a continual polling by the operating system. Maybe the term isn't used much any more.

All of the actions needed to retrieve programs from the hard disk drive and other storage to achieve a state whereby the next move is up to the user or the environment is included in what I have been calling the reset program.

If the system does nothing after it has been made ready to serve the user or the environment outside of the computer, and services are performed only in response to hardware interrupts from peripheral devices, the operating system is purely interrupt driven. A once-per-second interrupt from a cock, or a press of a key on a keyboard would be examples of hardware interrupts.

The reset program is complicated not only by the need to retrieve programs from storage, but also by the need to check for hardware options that may not exist the same way in all computers using the operating system.

In any case, there comes a time when the computer waits without polling.

Depending on a number of factors, some interrupt input signals may be temporarily disabled. If the system is running a program that controls a robot arm that is pouring coffee, that program may be written to disallow input from a clock tick for a while.

There seem to be real-time versions of Linux. I don't know whether they are purely interrupt driven or just permit some programs to perform in that way. I would provide a link, but I think they are disallowed by the forum. My email address was rejected in my first post above.

Jim Adrian
Click to expand...
What you are referring to is probably preemption. All versions of the Linux kernel after 2.6 are almost fully preemptible in that most of the kernel processes can be preempted by an 'event'.
https://en.wikipedia.org/wiki/Linux_kernel#Preemption

I don't know of any distros that support fully event driven process management (non-preemptible) since that would possibly allow userland processes to never give control back to the kernel.

http://www.informit.com/articles/article.aspx?p=414983&seqNum=2
 
Last edited:
Nice thread, lets just say Ive been on the case as soon as I sensed the disturbance in the force. Been researching things Id normally not bother with, I guess the point trying to be maid is all too clear now... If I was homer simpson Id probably be blissfully unaware, maybe a little crazy. Mum is the word, Im just a regular guy, working jobs that don't sound half as interesting as these last couple weeks have been...

The idea though, however worded, its good thought. Ive been forced to try and go about it from the outside in, needless to say ive got the source and im looking at how best to menuconfig before I compile it... Im obsessed with apt-get and like someone said to me a long time ago, "you trust everything on github" of course I did, now Im not so sure about anything... Never had been ooooh no a pop up, and most of the time, its just stay clear of executables. Now injection, and I wont speculate further, but Im not even sure uninteruptable kernels will help from what I can tell
 
If you google
open source automation development lab osadl
you will find Realtime Linux, and that is the page I would like you all to see.

I shall return.

Jim Adrian
 
Thank you ryanvade for your very valuable information.

I am primarily concerned about the Linux community coming to fully support robotics, machine control, and all sorts of automation. It is very important to the economy.

It is reasonable for a robot to be interrupted by a non-maskable interrupt caused by a fire alarm and it should be routine for it to be interrupted by sensory conditions, or a stop button, but there should be a way to prevent, at least for a designated period of time, the sharing of processor time with a spread sheet program under the scheduling assumption that no program needs real-time computing.

Windows and OS X are nowhere on this. Serving these customers will increase Linux market share. That would be a good thing, in my opinion.

Jim Adrian
 
James Adrian said:
Thank you ryanvade for your very valuable information.

I am primarily concerned about the Linux community coming to fully support robotics, machine control, and all sorts of automation. It is very important to the economy.

It is reasonable for a robot to be interrupted by a non-maskable interrupt caused by a fire alarm and it should be routine for it to be interrupted by sensory conditions, or a stop button, but there should be a way to prevent, at least for a designated period of time, the sharing of processor time with a spread sheet program under the scheduling assumption that no program needs real-time computing.

Windows and OS X are nowhere on this. Serving these customers will increase Linux market share. That would be a good thing, in my opinion.

Jim Adrian
Click to expand...
In terms of robotics I don't see why the kernel would need to be fully real time in order to accomplish what you are suggesting about being interrupted by sensory data. Userland libraries are able to achieve this already without modification to the scheduler. For example, look at the KIPR Wallaby. The controller is just for kids but underneath it is actually very powerful running a modified Yocto Linux distro with a quad core arm processor and a co-proecessor for other computations. The system is not running in real time if I recall correctly yet it allows students to program for input sensory data to trigger events and there is an overall timer that can trigger events outside of their control.

https://github.com/kipr/wallaby

I do, however, agree that more real-time fully opensource distros could only strengthen the Linux community. I just see no reason why the current level of preemption is not sufficient for robotics, machine control/learning, and the like. For most applications real time calculations should be offloaded to a microcontroller instead of, for example, an SBC.

Another example is the Pine 64. You can connect an RTC and have proper interrupts.
http://www.tldp.org/LDP/tlk/dd/interrupts.html
 
Last edited:
ryanvade,

I don't fear an inability to interrupt a robotic program. I fear an insufficient ability to prevent interrupts at critical times in the course of robotic action. If this can be managed with existing distributions, we might declare victory and site the failure on the part of Windows and OS X to take care of this.

For many reasons, I regard Python the most evolved and useful computer programming language. Among many other attributes, it supports parallel processing. The processors in most PC and iMac computers have multiple cores. That advantage seems to be underused. These facts together may make any needed adjustments easier than they otherwise would be.

I would be very pleased if some or all distributions of Linux characterized themselves as Robotics Ready. This might be possible now.

Jim Adrian
 
I should add that using external development systems or having them made as Windows and OS X require adds very much more cost. You don't need to add an external microcontroller if you have a robotics-ready Linux distribution in your desktop.

Jim Adrian
 
Does anybody know how to contact the people who write new or updated distributions of Linux?

Jim Adrian
 
You might want to join or read the Linux Kernel Mailing List.

As for the Distros, you would need to contact the individual authors for the various Linux Distributions, listed at Distowatch. You would have to go to the website for each Distro and look up the authors for each one.
 
You must log in or register to reply here.

Members online

Total: 814 (members: 2, guests: 812)

Latest posts

Top