[ECOS] RE: Reentrancy of the ecos drivers

harbonne marc marc.harbonne@silicomp.fr
Tue Jul 18 14:52:00 GMT 2006

Ok, can you point me to the ecos resources management of one the drivers


-----Message d'origine-----
De : Gary Thomas [mailto:gary@mlbassoc.com] 
Envoyé : mardi 18 juillet 2006 16:48
À : harbonne marc
Cc : ecos-discuss@ecos.sourceware.org
Objet : Re: [ECOS] RE: Reentrancy of the ecos drivers

harbonne marc wrote:
> The driver I speak about is the ipaq touch screen present under
> /devs/touch/ipaq but my remark concerns also the i82559 ethernet driveror
> any other driver, so If I understand it is the responsibility  of the
> developer to make its own protection if he wants to share the same
> between two or more tasks ?
> It means that theses drivers are not re-entrant ?

There's no need for them to be.  As I said before, the upper layers handle
such concurrency and resource management.

In the case of the network driver, there are multiple layers of networking
stack between "user" code and the driver.  These layers handle any resource
management.  Of course, if you don't use one of the standard stacks, then
you'd have to solve the problem yourself.

Note: this is why such management is performed at higher layers - that way
the individual drivers don't need to be complicated with such tasks.

The touch screen is similar - the most common use is via the MicroWindows
package which then handles the device and provides a shared resource to
the various threads.

What sort of reentrancy are you concerned about?

> Regards
> Marc 
> -----Message d'origine-----
> De : Gary Thomas [mailto:gary@mlbassoc.com] 
> Envoyé : mardi 18 juillet 2006 14:26
> À : harbonne marc
> Cc : ecos-discuss@ecos.sourceware.org
> Objet : Re: [ECOS] RE: Reentrancy of the ecos drivers
> harbonne marc wrote:
>> Hi all,
>> My question is quite general, I cannot see in any ecos drivers provided
> with
>> the last version of ecos, a way to protect the shared resources.
>> As example, if you look at any display driver, we cannot see a semaphore
>> that will protect from a second task to access to the resource by
>> pre-empting the one which has the resource.
>> The only call I can see is a cyg_scheduler_lock and unlock to get/release
>> the resource.
>> But in many drivers such mechanism does not exist.
>> Can you tell me why?
> In most cases, such resource management (if it's required) is handled
> at a level higher than the physical device driver.
> What driver(s) are you concerned about?

Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world

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

More information about the Ecos-discuss mailing list