This is the mail archive of the ecos-discuss@sourceware.org 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: Implementing callback from driver to application


On 8/5/07, Gary Thomas <gary@mlbassoc.com> wrote:
> Mike Sweeney wrote:
> > I have a custom device driver that needs to invoke a callback function
> > that is registered by the user's application. I have a 3 level
> > interrupt service mechanism within my device driver: an ISR, a DSR,
> > and an interrupt service thread. Basically in my interrupt service
> > thread I invoke the callback function. This is not a great design
> > because I don't want to be blocked in my interrupt service thread for
> > an unknown amount of time. I may have multiple application callbacks
> > to invoke depending on the device status.
> >
> > I'm looking for some input on how best to tackle this within eCos. My
> > design requires the kernel so I can use any sort of kernel services
> > and am not restricting myself to the driver API. Should my driver have
> > another dedicated thread that receives mailbox messages from my
> > interrupt service thread and then calls the callbacks from within its
> > own context? All ideas are appreciated.
>
> Yes, this is the preferred method (threads are quite cheap).
> Your driver thread can then call back into the user code, block,
> etc, without affecting the rest of the system.
>
> Note: a good usage example of this is the input processing
> thread in the FreeBSD networking stack.
>

Thanks Gary. I'll check out the code you mentioned.

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