Hi all..
I have tried to port Linux for using as a embedded RTOS.
For confirming feasiblity, I have analyzed kernel source.
After the analysis I knew that it is impossible, at the present time.
Too many jobs are ran in the kernel mode(even TCP/IP processing).
And, variable length of critical sections present.
And, the size of kernel and application is too big.
RT-linux can solve some problems which are caused by event latency.
But, RTlinux solution can't be called as a embedded RTOS.
Most commercial RTOS can run under 1Mbyte memory space without disk or
flash device, but still support complete function.
Linux kernel should be redesiged carefully if we want Linux to be
applied to a embedded RTOS.
If embedded version of Linux kernel is developed, it may be a RTOS itself.
In my opinion, we would like to stop port Linux to embedded OS(not RTOS)
without redesinging simple Linux kernel and device drivers.
Linux is too intelligent to use for the embedded application.
Please don't fit your system in existing kernel, but fit kernel
in your system.
I want ... future linux release have the following options.
CONFIG_EMBEDDED ; supress extra-code for supporting complex function.
CONFIG_KERNEL_TASK ; run kernel as a task.
:-)
Can Linux win in the embedded OS market against Windows CE in the future?
<APPENDIX A> Difference between hard and soft realtime.
Hard-realtime is based on the deadline.
If a event was not processed within pre-defined time(deadline),
it means that control system is failed to process job.
There are a few applications which are required hard-realtime system.
Soft-realtime is based on the priority.
If 1)all tasks are preemtible immediately and 2)portion of running time
at the kernel mode is very short, it can be called as a (soft)RTOS.
How about Linux?
WMWMWMWMW MWMWMWMWM WMWMWMWMW MWMWMWMWM WMWMWMWMW MWMWMWMWM WMWMWMWMW
M YoungChan Yoon Dept. of Automation Engineering M
W email) [EMAIL PROTECTED] Inha University, Korea W
M URL ) http://rcsl.inha.ac.kr/~treeman M
WMWMWMWMW MWMWMWMWM WMWMWMWMW MWMWMWMWM WMWMWMWMW MWMWMWMWM WMWMWMWMW
On Thu, 5 Nov 1998, Jim Dennis wrote:
>
>
> > Hello all,
> >
> > I'm hoping to move our next-generation products to a StrongArm/embedded
> > Linux platform but have met resistance from some who contend that
> > Linux cannot be used as an RTOS. I understand that Linux cannot
> > complete directly with the likes of a real RTOS, say from Pharlap,
> ^^^^^^^^
> = compete?
>
> > but if your RTOS requirements are minimal, the advantages of
> > having an open-source based system, with the huge amount of
> > software available, outweigh the RTOS deficiencies of Linux.
>
> Cygnus has apparently just released their eCOS RTOS
> --- it was developed a few years ago; and they've been
> trying to release it to GPL to follow the mainstream of
> their business model; but they were held up by some of their
> business associates.
>
> Look at the Cygnus web site for details.
>
> > With an embedded Linux, I assume you can still service your
> > interrupt routines without having to make system calls. Please
> > correct me if I'm wrong.
>
> > So, any thoughts about Linux as an RTOS?
>
> Personally I still think that Linux is a pretty silly choice
> for *embedded* systems. I think its an excellent choice
> for turnkey systems (info appliances, X and ether terminals,
> NC's, vertical systems like "lanalyzers" that sort of thing).
>
> However, I'm probably splitting hairs in a field that has
> long since blurred the distinction that I'm thinking of.
>
> I think of "embedded" OS' as things that are measured in K
> or 10's of K. Hundreds of kilobytes and megabytes are a
> different realm.
>
> Nonetheless the real-time factor is a bit of a red herring.
> There are RT patches for Linux. There are also some
> alternative bits of scheduling code that various people have
> played with --- and some of these have been discussed
> extensively on the kernel mailing list.
>
> (There was some talk of a dual run queue that apparently
> gave pretty good "soft real-time" performance, suitable for
> playing MPEG's, audio and IP telephony).
>
> So, you have some choice that are already out there (some in
> the form of unofficial kernel patches. More importantly you
> have considerable evidence that the structure of the kernel
> sources makes it feasible for a good programmer to
> experiment with and implement their own schedulers, and to
> run the entire Linux kernel under any number of microkernels
> (RTLinux implements a minimal mk and runs Linux as the major
> "idle time" task under it; additionally version of Linux
> have been modified and run under the Mach, L4, and L5
> microkernels).
>
> > Thanks,
> > Chuck
>
> --
> Jim Dennis (800) 938-4078 [EMAIL PROTECTED]
> Proprietor, Starshine Technical Services: http://www.starshine.org
>
