From: Andrew Lunn <andrew@lunn.ch>
To: Samie Hassan Ghauri <samiehg@hotmail.com>
CC: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Thread model and software interrutps
Date: Fri, 1 Oct 2004 17:18:27 +0200
On Fri, Oct 01, 2004 at 02:58:15PM +0000, Samie Hassan Ghauri wrote:
> In the eCos code repository, apart from the drivers written for
ethernet,
> none is written as a thread. Seeing the driver from the hardware point
of
> view, this is understandable that perhaps none require too complex a
device
> handling that the driver had to be written as a thread.
The network stack is not a real time service. It can also run for a
long time in some code paths. Thus putting it in a DSR where it cannot
be preempted by higher priority real time tasks makes no sense for an
RTOS. All the other driver have short code paths in ISRs and DSRs so
they will not add much latency for high priority tasks.
> 1. However, seeing the driver from application point of view, they
only
> exist as function calls (I/O subsystem API). Why is this? Why cant an
> application pass some data to the driver for processing, through these
API
> and then the driver would start running as a thread in parallel with the
> thread in the application (i.e. the thread that passed this data) ?
What you are talking about is effectively asynchronous I/O. Adding
this at the driver level adds additional complexity which 99% of
applications don't need. The other 1% can easily implement it
themselves above the drivers.
> 2. Sometimes in operating systems the applications are interfaced with
the
> kernel via software interrupts. eCos does not seem to provide constructs
> for any such implementation. Is it right?
Interrupts are used so that you can change protection domains, ie jump
from user space into kernel space in *nix like systems. eCos does not
have any protection domains so such mechanisms are not needed. Also,
by linking to the actual functions, the linker can remove code that is
not used so making the image smaller. Using the interrupt scheme would
require that all of eCos is needed in the image even when its not
actually used.
Andrew