dynamic loading was Re: i386/parallel port

[gregory.menke at gsfc.nasa.gov]

 > Folks here seem to speak from a kind of knowing I
 > don't posses. RTEMS is still just a mysterious black
 > box without a whole lot of practical documentation for
 > it's inerds. Almost all the documentation that does
 > exist seems to be written with the assumption that one
 > should already know all about every rtos and so the
 > docs don't need to deal with the step by step
 > evolution of a device driver (for example).
 > 
 > It would seem to know what I must about whether RTEMS
 > will even do what I want I have to reverse engineer
 > it. One might say that my comments are unfair do to
 > the newness of the os, but based on the extent to
 > which documentation has been written I tend to feel
 > the needs of potential proponents, user, and bsp
 > writers of the OS have been overlooked.
 > 
 > 
 > Don't get me wrong, from what I've been able to learn
 > about RTEMS, I think it's neat, but learning about
 > it's true nature has been like pulling teeth. I don't
 > think it should have to be that hard.


It is pretty daunting to start with.  Its an interesting point because
internally, it isn't all THAT complicated, but it sure looks like it
is from the outside.  I found the biggest hurdle was understanding how
the GNU toolchain works (not that I claim I understand it now, but I'm
a bit more comfortable than I was...)

Honestly, more/better beginner documentation would be a tremendous
help.  But, naturally, its a question of resources.  OAR isn't Wind
River with its monopolistic gouging of its customers whenever they
start a new project or get a new PC- so budgets are more limited.
We're moving thru working with Joel to get a bsp together for our
mips-based flight hardware & that helped me a lot to understand whats
going on.  Naturally, that isn't of much use to you either...

IMO, the question of writing drivers & bsps must be shelved until you
understand the system fairly well; how its constructed, where things
are in the source tree.  You'll also need to know how the compilers &
build system work for at least your target hardware.  Once you know
those things, there isn't a huge need for lots of documentation
because internally, RTEMS is fairly simple.

Your point about nearly having to reverse-engineer the system to know
how it works is pretty fair, the docs aren't the way to learn RTEMS-
they're helpful for reference, but I've found as I get familiar with
it, I look at code more and more for information.

It might be worth noting that its also possible an RTOS that insulates
you from needing an understanding of it to an equivalent degree is
letting you be ignorant of internal issues that you really should be
aware of if your application is at all complex or important.

The cross-platform nature of RTEMS was for me the most frustrating
part of trying to understand what its doing; there was never a clear
path to follow thru the code & the layers of #defines made it
essentially impossible.  I've learned considerably more by trying to
understand whats going on in a particular bsp & cpu, not in general.
This stuff is at a pretty low level, so it doesn't tell you whats
going on in the upper levels- but you can start to match up the
documentation as it stands to the stuff associated with the actual
hardware & operations.

Just my .02, YMMV.

Gregm