This is the mail archive of the ecos-discuss@sources.redhat.com 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: processes vs threads (MMU protection)



Thomas.Binder@frequentis.com wrote:

> 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.

This looks fantastic to me. We have different products with different level
of complexity. What I would like to do is being able to decide through
configuration
(and this is the key factor of eCos, right?) whether I want to include the MMU
support or not!

>
>
> >
> > 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).
>

Where can I find some of the 'literature' you are reffering to?
This is just my curiosity ...

>
> > 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.
>

Is the documentation of how to port the HAL for supporting MMU already
available? Yes, I know ... we can't do anything without the kernel support,
but I'm curios to see what must be done to have such a support ...



>
> 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.
>

Yes, there are issues in embedding Linux in small devices, but I can understand
Nick's concerns about possible destabilization of eCos' source tree.

What I think it could be valuable is to understand how many people could
be interested in having such a feature in their products ...

Regards,
    Armando

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


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


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