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: 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 resource
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


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