This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Thread model and software interrutps


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

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]