public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* [ECOS] Re: Memory protection
       [not found] ` < 006201be19cc$b8311600$bc314ed1@speedy >
@ 1998-11-27  7:04   ` Bart Veer
  0 siblings, 0 replies; 5+ messages in thread
From: Bart Veer @ 1998-11-27  7:04 UTC (permalink / raw)
  To: c.waters; +Cc: ecos-discuss

>>>>> "Chris" == Chris Waters <c.waters@celsius.co.nz> writes:

    Chris> From what I can see at the moment ecos provides no support
    Chris> for memory protection. Does anyone have any feel for how
    Chris> easy/hard it would be to add memory protection to the
    Chris> kernal for processors that provide it?

The question here is exactly what you want memory protection for?
The current eCos system is oriented towards multi-threaded
applications rather than multitasking. It is assumed that the
application consists of multiple threads which interact through a
single shared address space, using appropriate synchronisation
primitives such as mutexes and condition variables to control access
to this shared data. In this model memory protection makes little
sense (although some useful debugging tricks become possible).

Memory protection is appropriate for a different type of system where
there are multiple tasks or processes in separate address spaces, and
interaction between the processes happens via e.g. pipes and mmap()'d
regions. There are some very significant overheads associated with
this model. Enabling the MMU properly requires significant code
overheads becausing initializing and managing an MMU is non-trivial.
There are data overheads because you need page tables etc. There are
some run-time performance penalties associated with memory accesses.
Typically interactions between separate processes require one or more
system calls and hence crossing protection boundaries, which is
expensive. Finally kernel calls usually have to involve a system trap
which adds more overhead and which makes it much more difficult to
eliminate functionality that is not actually needed by the
application. 

The current version of eCos is intended to support the deeply embedded
part of the market, without precluding more advanced applications. The
assumption has to be that cpu cycles and all types of memory will be
in short supply, and many applications would not want to enable the
MMU even if support was available. Therefore we have not yet
implemented any form of memory protection in eCos, we have
concentrated our efforts on other parts of the system. On some
architectures it is necessary to a do a certain amount of MMU
manipulation to get e.g. the cache working, see the PowerPC MPC860 HAL
package for an example. It should be possible to hook into that and
set up a particular address map that meets the application's
requirements - the current release would need a little bit of tweaking
for this.

In the medium to long term we are likely to add some support for MMUs.
This will be configurable so that application developers can examine
the costs and the benefits involved, and decide for themselves whether
or not it is worthwhile. There are actually a number of possible uses
for MMUs:

1) it provides a way of doing automatic stack extension with
   relatively low overheads. This is useful for more complicated
   applications where it may be too difficult to determine stack
   requirements by static analysis. It does restrict stack sizes to
   multiples of the hardware page size.

2) if there is some sort of access to the outside world, e.g. via an
   internet connection, it is possible to download system patches and
   set up the MMU so that some bits of the system get executed from
   RAM rather than from ROM. For some applications this can provide a
   cost-effective alternative to flash memory.

3) if the ROM is a scarce resource then it is possible to store some
   of the code in a compressed form, decompressing it into RAM as and
   when required. The MMU provides a way of detecting accesses to code
   that is not currently available in RAM.

4) limited protection support, primarily for debugging purposes, for
   example the ability to invalidate certain parts of the address
   space like location 0.


Bart Veer // eCos net maintainer

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Memory protection
@ 1998-11-27  7:04 Chris Waters
       [not found] ` < 006201be19cc$b8311600$bc314ed1@speedy >
  0 siblings, 1 reply; 5+ messages in thread
From: Chris Waters @ 1998-11-27  7:04 UTC (permalink / raw)
  To: ecos-discuss

Hi,

From what I can see at the moment ecos provides no support for memory
protection. Does anyone have any feel for how easy/hard it would be to add
memory protection to the kernal for processors that provide it?

I am thinking about porting ecos to the IBM PowerPC 403GC.

Chris Waters.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Memory Protection
  2002-04-24 23:44 ` Jesper Skov
@ 2002-04-30 14:07   ` Jonathan Larmour
  0 siblings, 0 replies; 5+ messages in thread
From: Jonathan Larmour @ 2002-04-30 14:07 UTC (permalink / raw)
  To: Victor Volpe; +Cc: eCos Discuss

Jesper Skov wrote:
> 
> On Wed, 2002-04-24 at 22:31, Victor Volpe wrote:
> > I could not find any information on memory protection in the documentation.
> > Can someone let me know if eCos has MMU support and if it does, does it
> > support per thread memory protection.
> 
> No (in the sense you are probably think about) and no.

Although if you happen to be using the SA1110, you may want to look at
http://www.3glab.org/

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [ECOS] Memory Protection
  2002-04-24 13:34 [ECOS] Memory Protection Victor Volpe
@ 2002-04-24 23:44 ` Jesper Skov
  2002-04-30 14:07   ` Jonathan Larmour
  0 siblings, 1 reply; 5+ messages in thread
From: Jesper Skov @ 2002-04-24 23:44 UTC (permalink / raw)
  To: Victor Volpe; +Cc: eCos Discuss

On Wed, 2002-04-24 at 22:31, Victor Volpe wrote:
> I could not find any information on memory protection in the documentation.
> Can someone let me know if eCos has MMU support and if it does, does it
> support per thread memory protection.

No (in the sense you are probably think about) and no.

Jesper


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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [ECOS] Memory Protection
@ 2002-04-24 13:34 Victor Volpe
  2002-04-24 23:44 ` Jesper Skov
  0 siblings, 1 reply; 5+ messages in thread
From: Victor Volpe @ 2002-04-24 13:34 UTC (permalink / raw)
  To: ecos-discuss

I could not find any information on memory protection in the documentation.
Can someone let me know if eCos has MMU support and if it does, does it
support per thread memory protection.

Please respond directly to me since I have not joined the mailing list yet.

Thanks,

Victor

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2002-04-30 21:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-11-27  7:04 [ECOS] Memory protection Chris Waters
     [not found] ` < 006201be19cc$b8311600$bc314ed1@speedy >
1998-11-27  7:04   ` [ECOS] " Bart Veer
2002-04-24 13:34 [ECOS] Memory Protection Victor Volpe
2002-04-24 23:44 ` Jesper Skov
2002-04-30 14:07   ` Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).