All RTOS (linux Based ) Other than RT-Linux

mahi wrote:
> Hi all, I want to know, there are any REAL TIME OPERATING
> systems( RTOS) which should have total linux compatible other than RT-
> Linux.
>
> And are there any free Real time Operating systems ( Linux Based ) is
> available on the Internet.
>
> Please provide some information regarding this issue.

I have read that the kernel is interrupt driven rather than schedule driven. If
that is what you mean, all linuxes are real time.

--
The purpose of peace talks between Palestine and Israel is to prevent
Palestine from ever being free of the Israel occupation.
-- The Iron Webmaster, 3842
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
commentary http://www.giwersworld.org/opinion/running.phtml a5

Matt Giwer wrote:
> mahi wrote:
>> Hi all, I want to know, there are any REAL TIME OPERATING
>> systems( RTOS) which should have total linux compatible other than RT-
>> Linux.
>>
>> And are there any free Real time Operating systems ( Linux Based ) is
>> available on the Internet.
>>
>> Please provide some information regarding this issue.
>
> I have read that the kernel is interrupt driven rather than schedule
> driven. If that is what you mean, all linuxes are real time.
>
Thats not generally enough for many peoples definitions, which is that
the time to respond to an (external) interrupt is fast, un blockable,
and well defined.


If you think of how many ways to stop your 'lunix' responding to a
keyboard interrupt exist, you will get my drift.

Most RTOSes are very lightweight and very carefully controlled in terms
of response time to interrupts.

The Natural Philosopher wrote:
> Matt Giwer wrote:
>> mahi wrote:
>>> Hi all, I want to know, there are any REAL TIME OPERATING
>>> systems( RTOS) which should have total linux compatible other than RT-
>>> Linux.
>>> And are there any free Real time Operating systems ( Linux Based ) is
>>> available on the Internet.
>>> Please provide some information regarding this issue.
>> I have read that the kernel is interrupt driven rather than
>> schedule driven. If that is what you mean, all linuxes are real time.

> Thats not generally enough for many peoples definitions, which is that
> the time to respond to an (external) interrupt is fast, un blockable,
> and well defined.

I realize there are many definitions. However what you suggest is what "nice"
is for. Having a real time OS and tailoring it are two different matters.

> If you think of how many ways to stop your 'lunix' responding to a
> keyboard interrupt exist, you will get my drift.

Change the BIOS to no keyboard? Or something like that. The keyboard is not a
linux function. It only reads the BIOS.

> Most RTOSes are very lightweight and very carefully controlled in terms
> of response time to interrupts.

I have never become involved in tailoring a OS compile to single applications.
I have no idea how to do it. I have READ killing all the unneeded material is
possible.

--
Republicans are more interested in protecting the president than the troops.
-- The Iron Webmaster, 3839
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
flying saucers http://www.giwersworld.org/flyingsa.html a2

Matt Giwer wrote:

>> Hi all, I want to know, there are any REAL TIME OPERATING
>> systems( RTOS) which should have total linux compatible other than RT-
>> Linux.
>>
>> And are there any free Real time Operating systems ( Linux Based ) is
>> available on the Internet.
>>
>> Please provide some information regarding this issue.
>
>
> I have read that the kernel is interrupt driven rather than schedule
> driven. If that is what you mean, all linuxes are real time.

Real time systems typically guarantee some timing (interrupt
latency...), so that processes can react on events in a timely manner.
Furthermore the response on events has time constraints, i.e. a process
must lower its priority, after doing the time critical event handling.
This requires that *all* system processes behave accordingly, what's not
normally the case in an preemptive multitasking system. A related
requirement are memory-resident event handlers, separated somehow from
the less critical swappable parts of an process.

IMO these requirements cannot be satisfied with the public Linux code,
and also cannot be introduced by simple patches to the kernel etc. sources.

Some approaches make the Linux kernel simply an process, running under
control of an new RT kernel. But then RT processes will have to
communicate and cooperate with the RT kernel, so that they run more in
parallel to the Linux kernel, instead of controlled by the Linux kernel.
IMO it then is inevitable to split RT applications into an RT process,
running under control of the RT kernel, and an non-RT process, running
under control of the Linux kernel. One also might see the RT part as
kind of a device or driver, interacting with the remaining part of the
application.

IMO it will be simpler to use some available RT system, and make it's
ABI so Linux-compatible, that Linux applications can be installed into
such a system. But then it might be easier to install a veritable Linux
into a VM, hosted by the RT OS. See also: The Xen Project.

DoDi

Matt Giwer wrote:
> The Natural Philosopher wrote:
>> Matt Giwer wrote:
>>> mahi wrote:
>>>> Hi all, I want to know, there are any REAL TIME OPERATING
>>>> systems( RTOS) which should have total linux compatible other than RT-
>>>> Linux.
>>>> And are there any free Real time Operating systems ( Linux Based ) is
>>>> available on the Internet.
>>>> Please provide some information regarding this issue.
>>> I have read that the kernel is interrupt driven rather than
>>> schedule driven. If that is what you mean, all linuxes are real time.
>
>> Thats not generally enough for many peoples definitions, which is that
>> the time to respond to an (external) interrupt is fast, un blockable,
>> and well defined.
>
> I realize there are many definitions. However what you suggest is
> what "nice" is for. Having a real time OS and tailoring it are two
> different matters.
>

With respect, it isn't.

>> If you think of how many ways to stop your 'lunix' responding to a
>> keyboard interrupt exist, you will get my drift.
>
> Change the BIOS to no keyboard? Or something like that. The keyboard
> is not a linux function. It only reads the BIOS.
>

Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
linux. Their sole function is to get the OS in place with some form of
basic keyboard and screen control. In case intervention is needed.

After that the interrupt routines are installed by the kernel for pretty
much everything.


>> Most RTOSes are very lightweight and very carefully controlled in
>> terms of response time to interrupts.
>
> I have never become involved in tailoring a OS compile to single
> applications. I have no idea how to do it. I have READ killing all the
> unneeded material is possible.
>

Well it depends on what application you want to run..if its simple
enough you probably wouldn't bother with an OS at all. Or you would
write your own...it becomes less a question of what you remove that what
you decide to include..you wouldn't need multiuser capabilities
normally, though you might leave in a hierarchy of task priorities..you
might not even need a strict multitasking ability. If the program does
just one thing, that is processing some real time event and turning it
into an output, you can leave the processor in either a halt state, or
running in a null loop till an interrupt comes along.

Linux is a multiuser, multitasking general OS. Its not designed for real
time work. People use it and work round that by stripping it down and
having enough processor speed to cope with its deficiencies, and hoping
no bug or unforeseen events slow it or crash it..but is not the best way
to crack a real real-time application.

It's easier to buy in a proper RTOS with libc support and compile linux
stuff to that..if you want REAL millisecond response times.

The problem with Linux as its stands is that lots of stuff inside the
kernel may wait indeterminate times with most or all interrupts
disabled, waiting for a peripheral to respond. Sure mostly this is
engineered out for common cases: but there's plenty pf times that a
buggy bit of code can freeze out the rest of the machine by hogging
cycles or calling into the kernel to do something that doesn't complete
in a timely fashion. Where defined response times are a matter of life
and death - like in avionics, you will not find Linux.

Matt Giwer wrote:

>> Thats not generally enough for many peoples definitions, which is that
>> the time to respond to an (external) interrupt is fast, un blockable,
>> and well defined.
>
> I realize there are many definitions. However what you suggest is what
> "nice" is for. Having a real time OS and tailoring it are two different
> matters.

Actually, "nice" is for batch jobs vs interactive ones. Has nothing to do
with interrupts.

However, there are real-time extensions to Unix/Linux which allow fixed
priorities, no swapping, task activation/resumption on specified interrupts,
etc.. While not enough for "hard" real time with rapid responses, the
extensions are more than adequate for the average process control or SCADA
system. One of the projects I was involved in ran an aluminum smelter SCADA
system. It's been installed in several smelters around the world. Works
fine.

Use of the extensions does take a little getting used to. For example, to run
a task every 5 milliseconds one does not exit and request reactivation in the
said 5 milliseconds. Instead, request the time when activated and at the end
of each iteration request reactivation or resumption in 5 milliseconds minus
however long the current iteration took.

--
It's turtles, all the way down.

The Natural Philosopher wrote:
> Matt Giwer wrote:
....
>> Change the BIOS to no keyboard? Or something like that. The
>> keyboard is not a linux function. It only reads the BIOS.

> Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
> linux. Their sole function is to get the OS in place with some form of
> basic keyboard and screen control. In case intervention is needed.

I guess I have been confused by the necessity to have the BIOS reflect new
hardware before linux notices it is there.

--
As pf July 2007, the Iraq war is costing the same as three nuclear aircraft
carriers every month. Never again question the cost of a carrier.
-- The Iron Webmaster, 3841
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
Israel says no extermination
http://www.giwersworld.org/holo3/holo-survivors.phtml a13

Matt Giwer wrote:

> The Natural Philosopher wrote:
>> Matt Giwer wrote:
> ...
>>> Change the BIOS to no keyboard? Or something like that. The
>>> keyboard is not a linux function. It only reads the BIOS.
>
>> Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
>> linux. Their sole function is to get the OS in place with some form of
>> basic keyboard and screen control. In case intervention is needed.
>
> I guess I have been confused by the necessity to have the BIOS reflect new
> hardware before linux notices it is there.
>

And right here you made the next error
--
Failure is not an option. It comes bundled with your Microsoft product.

Peter Köhlmann wrote:
> Matt Giwer wrote:
>> The Natural Philosopher wrote:
>>> Matt Giwer wrote:
>> ...
>>>> Change the BIOS to no keyboard? Or something like that. The
>>>> keyboard is not a linux function. It only reads the BIOS.
>>> Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
>>> linux. Their sole function is to get the OS in place with some form of
>>> basic keyboard and screen control. In case intervention is needed.
>> I guess I have been confused by the necessity to have the BIOS reflect new
>> hardware before linux notices it is there.

> And right here you made the next error

Odd that it is required. Perhaps you could take the time to explain.

--
Hodie postridie Nonas Augustas MMVII est
-- The Ferric Webceasar
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
Old Testament http://www.giwersworld.org/bible/ot.phtml a6

Matt Giwer wrote:
> Peter Köhlmann wrote:
>> Matt Giwer wrote:
>>> The Natural Philosopher wrote:
>>>> Matt Giwer wrote:
>>> ...
>>>>> Change the BIOS to no keyboard? Or something like that. The
>>>>> keyboard is not a linux function. It only reads the BIOS.
>>>> Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
>>>> linux. Their sole function is to get the OS in place with some form of
>>>> basic keyboard and screen control. In case intervention is needed.
>>> I guess I have been confused by the necessity to have the BIOS
>>> reflect new
>>> hardware before linux notices it is there.
>
>> And right here you made the next error
>
> Odd that it is required. Perhaps you could take the time to explain.
>

Th BIOS merely provide a set of routines that are hopefully

- enough to get the machine to boot something else and
- MAY be used by whatever else runs to access the hardware, but its only
MAY.

In fact most OS'es these days simply use the BIOS to bootstrap the boot
loader, and maybe access the boot disk: Once the OS is loaded it is
completely bypassed.

So in reality, all the BIOS dos in most systems is run the disk system
and select a boot drive, and provide a minimal amount of screen/keyboard
stuff for boot diagnostics.

The Natural Philosopher writes:
> In fact most OS'es these days simply use the BIOS to bootstrap the boot
> loader, and maybe access the boot disk

Linux itself does not use the BIOS at all. All bootloaders use it, but the
bootloader is not part of the OS.

> Once the OS is loaded it is completely bypassed.

Correct, but there may be hardware that is initialized by the BIOS.
--
John Hasler
john RemoveThis @dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA

The Natural Philosopher wrote:
> Matt Giwer wrote:
>> Peter Köhlmann wrote:
>>> Matt Giwer wrote:
>>>> The Natural Philosopher wrote:
>>>>> Matt Giwer wrote:
>>>> ...
>>>>>> Change the BIOS to no keyboard? Or something like that. The
>>>>>> keyboard is not a linux function. It only reads the BIOS.
>>>>> Shows how little you know..most ROM BIOSES are TOTALLY bypassed by
>>>>> linux. Their sole function is to get the OS in place with some form of
>>>>> basic keyboard and screen control. In case intervention is needed.
>>>> I guess I have been confused by the necessity to have the BIOS
>>>> reflect new
>>>> hardware before linux notices it is there.
>>> And right here you made the next error
>> Odd that it is required. Perhaps you could take the time to explain.

> Th BIOS merely provide a set of routines that are hopefully

> - enough to get the machine to boot something else and
> - MAY be used by whatever else runs to access the hardware, but its only
> MAY.

> In fact most OS'es these days simply use the BIOS to bootstrap the boot
> loader, and maybe access the boot disk: Once the OS is loaded it is
> completely bypassed.

> So in reality, all the BIOS dos in most systems is run the disk system
> and select a boot drive, and provide a minimal amount of screen/keyboard
> stuff for boot diagnostics.

What started this was my statement that the keypresses are found by accessing
BIOS.

However my experience is that all hardware changes have to be registered in
BIOS before they are recognized by the OS, linux or otherwise. I can see how
once in BIOS the OS knows what to "look" for and then deal with it.

Not having actually followed the motherboard traces from the keyboard plug to
see where they lead I cannot swear the BIOS is the only place where an OS can
get the keypresses. However if the BIOS is not needed what his the physical
access point the linux uses to get the keypress data?

--
Al Qaeda is back to its pre-911 strength of 300. I am so frightened I can
only laugh to relieve the anxiety. 300 is the highest US government estimate
of their numbers ever made public.
-- The Iron Webmaaster, 3831
nizkor http://www.giwersworld.org/nizkook/nizkook.phtml
commentary http://www.giwersworld.org/opinion/running.phtml a5

Matt Giwer wrote:

> Not having actually followed the motherboard traces from the
> keyboard plug to see where they lead I cannot swear the BIOS is the only
> place where an OS can get the keypresses. However if the BIOS is not
> needed what his the physical access point the linux uses to get the
> keypress data?

It depends on the physical device. A PS/2 keyboard is connected to
different hardware, and is served by a different handler, than is e.g. a
wireless USB keyboard. When the OS installs drivers, for all physical
devices, the drivers return the logical device type, e.g. display, HD.
On universal adapters, like SCSI or USB, every connected device can be
of an different type. The OS will send (or receive) requests to logical
devices, which are translated by the handler into commands to the
physical device.

DoDi