Embedded Linux questions

[Alan Dayley]

At 11:40 PM 10/31/01 -0700, you wrote:
>Difficult to say, since it depends on what CPU architecture is available,
>nice priority, and what scheduler priority have been assigned to the
>process. It also depends on _who_ the process is run as (I'm assuming root).
>Generally, on a single-processor, lightly loaded machine (approx 2-3
>processes running as root), Linux can get about 2-4ms switching times,
>though if you're doing heavy IRQ work, chances are that's going to increase
>fairly fast.
>
>What kind of process were you thinking of running? Eg: what is the general
>target for these kinds of applications?

The app would be running as root.  Lots of I/O on the PCI bus.  The base 
CPU would be a 586 class processor.  2-4ms switching is better than I 
thought.  I will have to discuss that with the design team.

>Possibly...
>In Linus Torvalds exact words, "In many cases I just think that RTLinux is a
>worse fix than the disease. I think RTLinux is perfect for those things that
>truly need latency guarantees: no OS at _all_ in the way. But using it for
>'normal' stuff like just streaming audio and video is overkill. They don't
>have microsecond latency requirements."
>
>According to the linux-kernel mailing list, it is possible to give your
>application realtime priority (this has little to do with the nice()
>priority and deals directly with the Linux scheduler) via a
>sched_setscheduler() call on a vanilla linux kernel. Thing is, the app has
>to be run as root to do this. An example pair of programs that do this is
>available in the archives at this URL:
>http://marc.theaimsgroup.com/?l=linux-kernel&m=100108757109536&w=2

Thank you! I will go look at the link.

>Well, first off, userland applications should _never_ do direct writes to
>I/O, DMA, or IRQ space -- that should be reserved for kernel operations,
>since you will never know when the kernel needs access to that specific
>space or address. Besides, the actual code for this operation has to go
>through a context switch just to run -- in other words, it's faster to do it
>in the kernel rather than in user space.

I figured that the app would have to run in kernel space.  No surprise there.

>If you absolutely need to do this, I'd suggest writing a driver and api for
>the vanilla Linux kernel, and if you decide on doing this, I'd stay _far_
>away from the RTLinux kernel. It has a ton of incredibly hackish code in
>there to provide the quick latency times (eg: <=1ms per task switch) and can
>make code managment quite difficult. Besides, as long as you're not doing
>anything that has a high priority in another task (eg: system call for a
>video capture routine via the V4L system), you shouldn't have a problem with
>task switch latencies.

Are you saying that a kernel space app would be the driver or that a user 
space app would call a driver to get kernel space access?

>If you're needing something with picoseconds of latency, I would _not_
>suggest any form of the Linux system for this use -- use a system that has
>very little, if any at all, of the OS in the way of the actual applications.

Yes, well that is our option that we use now so if we don't need or can't 
use additional features that a Linux kernel would bring, we can use our 
proprietary kernel on our new architecture.

The absolute _best_ source for information regarding this is the
>linux-kernel mailing list archives (don't bother subscribing to it -- far
>too much information is posted to make it useful for someone not doing core
>kernel work). They can be actively searched on the MARC mailing list
>archives at http://marc.theaimsgroup.com/?l=linux-kernel
>
>There are other list archives, but I've found them to have a poor, if any,
>search program, which makes looking for answers quite difficult.
>
>Also, if you're thinking about posting to it (they accept non-subscribed
>posting) have a look at the linux-kernel FAQ beforehand -- people tend to be
>rather busy and will ignore a post if you don't follow guidelines. The FAQ
>is available at http://www.tux.org/lkml

Excellent resources!  Thank you.

Alan