Re: [ECOS] processes vs threads (MMU protection)

[Thomas BINDER <Thomas dot Binder at frequentis dot com>]

Nick Garnett wrote:
> 
> Armando Visconti <armando.visconti@st.com> writes:
> 
> > I would like to ask to the mantainers why the work
> > done by 3G lab on 'memory protection' has not
> > been included in eCos v2.0.
> >
> > Is not stable enough?
> 
> That work was done a long time ago, against a very old version of
> eCos. It only addressed the issues that 3G Labs were concerned about
> at the time. It was also very specific to the ARM architecture.
> 
> > Don't you think it would be great for a MMU
> > based system to get benefit from a memory
> > protected OS ?
> > Any plan in this direction?
> >
> 
> Thomas Binder has recently submitted a patch to implement a form of
> process-like memory protection for PowerPC based devices. While I have
> not looked at this in great detail yet, it appears to suffer from some
> of the same problems as the 3G Labs work: it may be too specific to
> the PowerPC MMU model.

Hmm! I don't know the approach from 3GLabs, however, our process environment
(i.e. the classes that implement processes + the interface the user sees) is
*completely* architecture independent. All you need is a gcc2 or gcc3
compiler. The HAL needed to be changed to support the page table load
operation, that certainly *is* hardware dependent, but I guess that's what the
HAL is for. What needs further discussion is whether it is better to create a
new PPC HAL with MMU support, or to use compile time switches in the existing
one.


> 
> More generally, eCos was not designed to be a memory-protected
> operating system. I have implemented such systems in the past, and the
> approach taken needs to be very different. When originally
> implementing eCos we explicitly decided that a process-level memory
> protection system was not something we wanted to allow
> for. Consequently things like the APIs, kernel data structures and
> algorithms are not suitable.
> 

I don`t see why memory protection should not work with eCos, or break any
design issues. If you had looked into the patch I sent you a while ago Nick
you would see that we added many new classes instead of changing existing
code. The changes to the existing code (kernel, drivers) are small to
neglectable (e.g. only *two* lines of code had to be changed in the whole IP
stack). Besides, our approach has been suggested in literature and was already
successfully implemented (I think there's a citation of Millers paper in my
original post).


> To add a fully general, portable, process model to eCos would be
> months, if not years, of work. It would require significant rewrites
> of the kernel, the HALs and many other packages. The consequent
> destabilization of the source tree would be a significant blow to
> eCos' usability.

It took us approx. 6 months to implement HAL + process environment. I
would estimate another 2-3 months for each HAL that should be ported.

As to the mentioned stability issues, we found that the core dump feature of
our memory protection already proofed very useful in finding both kernel, and
application errors. For example the ecos timer bug that we recently submitted
was tracked down that way.  Our distributed voice/data switching application
that runs on 16 boards per rack has reached uptimes of more than two weeks
(after which the test was stopped. No crashes occurred!). The application
makes heavy use of TCP/IP, Ethernet, Serial, and PCI drivers.

> 
> My general attitude is that if you want processes, use an operating
> system that already supports them, like Linux.

Well, there are some differencies to Linux. Consider footprint, task switch
latency, and the set of synchronization primitives to name a few.

best regards,
Tom
--

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