[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Perfomance problems and main stream
- Date: Mon, 22 Feb 1999 08:34:19 -0800
- From: mark at oarcorp.com (Mark Johannes)
- Subject: Perfomance problems and main stream
It is my opinion that we are attempting to move the hardware integration
layers into a more modular set of components. For some time now, we as
users of RTEMS as well as developers and maintainers have been hindered by
the tight coupling of the "BSP" in whole to the executive and toolset
itself. The approach is the early stages of decoupling these entities to
provide for a more standalone kernel with multiple peripherals. I believe
that these discussions are healthy and that we welcome the technical
viewpoints of the user community. This foem of development team make RTEMS
better in the long run leveraging against the diverse talent pool.
I agree that the BSP is the area of most diversity, hence the problem.
What we are really attempting in to provide a framework and architecture
that allows this diversity to be applied without hindrance. Therefore, I
believe this will assist the newbie when a clear architecture is presented
for the structure that he/she has to integrate the application hardware
From: Jake Janovetz [SMTP:janovetz at tempest.ece.uiuc.edu]
Sent: Sunday, February 21, 1999 11:34 AM
To: Pollak Leon; rtems-snapshots at oarcorp.com
Subject: Re: Perfomance problems and main stream
I have not had much to do with the RTEMS development since I've
mainly been getting up to speed with how all this stuff works.
However, from my 'newbie' perspective, I would tend to agree
with you. Once I worked the current BSPs into something usable
for me, that part was done. In addition, it seems that that part
would need to be done regardless of how well the RTEMS folks
I would prefer to see (and help) development in other areas
of RTEMS to make it more up-to-date with other OSs that may be
competing with it. The two most recent HUGE additions have been
networking and filesystems. I consider that sort of work far more
valuable than anything else.
Although the libchip may be interesting, how much more complex
is it going to make things for a newbie. On the extreme, what
about a newbie who has to develop more than just a BSP, but new
material inside libchip?
On Sun, Feb 21, 1999 at 04:48:13PM +0200, Pollak Leon wrote:
> Dear RTEMS gurus,
> Please, forgive my interruption, I am interested in your opinion on this
> general question.
> For a long time I follow your mail exchange on different items on the
> list and I see that almost all the discussion is concentrated around
> different problems strongly connected to the different kinds of BSP's.
> Already several years I an totally involved into commercial products
> development and it seems to me, that the BSP's code in "hard real time"
> applications (this is the place where such fine RTOS's as RTEMS are
> applied) is very individual, I should say even intimate part of
> application. The same opinion I heard from other SW projects developers
> This doesn't mean that I suggest to refuse from using "predeveloped" BSP
> at all, the only thing I want to say is that such BSP's are of rather
> limited usage.
> So, are all of you sure, that it is worth to invest such a huge amount
> efforts in elaborating different concepts and testing new features of so
> detailed BSPs code, while IMHO there still is a place to improve the
> itself? May be we can concentrate our efforts on developing new drivers,
> file systems, TCP/IP area, tools independent code, task aware
> Once more, please, accept my excuses for my intervention.
> Dr.Leon M.Pollak
> PLR Information Systems Ltd.
> E-mail: leonp at plris.com
janovetz at uiuc.edu | Once you have flown, you will walk the earth with
University of Illinois | your eyes turned skyward, for there you have
| there you long to return. -- da Vinci
PP-ASEL | http://www.ews.uiuc.edu/~janovetz/index.html