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, 2004-10-01 at 08:58, 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.
> 
> 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) ?

You could easily do this, but for most devices there would be little 
gain for the added complexity.  Networking is a different case, as there
is a lot of processing that is "behind the curtain" on behalf of the
user application.

> 
> 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?

Again, you could do this, but since eCos applications are tightly bound
(i.e. linked) to the kernel, simple function call APIs are sufficient.

Remember what eCos was designed for - a highly configurable, efficient 
and flexible system for [deeply] embedded applications.  Adding the 
layers of complexity that you are asking for would undermine the basic
design premise (IMO).

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
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]