This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Re: Regd. the MMU in eCos1.3.1
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Rajan Srivastava <rajan at cdotd dot ernet dot in>
- Cc: eCos <ecos-discuss at sources dot redhat dot com>
- Date: Tue, 08 Apr 2003 02:02:43 +0100
- Subject: Re: [ECOS] Re: Regd. the MMU in eCos1.3.1
- References: <Pine.OSF.4.21.0304041209360.20258-100000@sagit.cdotd.ernet.in>
Rajan Srivastava wrote:
Hi,
The query launched by Mr Prabal is very much valid.
In follow-ups, it is said that why at all memory locking
is needed, let me elaborate the need.
Suppose I want some data to be protected against
accidental writes. If the page/segment is write protected,
eCos could generate an exception (write attempt on
RO page/segment) when some thread tries to
write on this area due to some coding bug.
So testing will become very easy.
Kindly see that eCos is getting so popular that
it has been widely accepted for realtime
embedded softwares, so these kind of lock
requirements should be met.
I agree, but see below....
Or you can guide us, how to write memory locking for
a given processor, eCos too can accept
this facility in its overall source-code
eCos is lightweight, and the burden of levels of page tables and so on
would make eCos less suitable for the low-end, so at best it would be an
option.
Some people say that we should always protect the text segment, and while
that's _mostly_ true, it isn't always, not least for things like software
breakpoints, nevermind self-modifying code (anathema in general, but can
be a useful tool in resource-constrained systems).
It would be good to have some scalable, flexible, lightweight and generic
API to allow people to fiddle with the MMU mappings, but this is _hard_.
MMUs are one of the areas that differ radically between MMUs and trying to
design an API in such a way as to prevent the API making life difficult
for the HAL porter would be tricky. So it hasn't happened.
Of course anyone is welcome to add HAL-specific MMU fiddling macros for
individual targets/variants/architectures, but something requiring the
amount of analysis that a generic API would require, would need funding
before it happens.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "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