Perfomance problems and main stream

[mark at oarcorp.com (Mark Johannes)]

Hello,

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

Sincerely,

Mark Johannes

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

Leon,

   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
handled BSPs.
   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?


    Cheers,
    Jake



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 
mail
> 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 
of
> efforts in elaborating different concepts and testing new features of so
> detailed BSPs code, while IMHO there still is a place to improve the 
RTEMS
> itself? May be we can concentrate our efforts on developing new drivers,
> file systems, TCP/IP area, tools independent code, task aware 
debugging...?
> 	Once more, please, accept my excuses for my intervention.
>
>
> Dr.Leon M.Pollak
> Director
> 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 
been,
                        | there you long to return.     -- da Vinci
        PP-ASEL         | http://www.ews.uiuc.edu/~janovetz/index.html