<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thomas Doerfler wrote:
<blockquote cite="mid45E5B4C6.5000005@embedded-brains.de" type="cite">
<pre wrap="">Robert,
all in all, I agree with Ralf. One nice feature of RTEMS maintenance is,
that OAR and Ralf can at least _build_ ALL BSPs when they test certain
modifications. If the virtex BSP relies on external code, this feature
would break.
</pre>
</blockquote>
As do I - I also agree with Ralf and what you just said. Perhaps I
should clarify - in fact, please forgive me for not being MUCH more
clear from the start. I have been making a distinction in my mind
between a "core BSP" (i.e. one that is fully integrated into the RTEMS
tree, introduces no new dependencies (other than the target hardware,
of course! <span class="moz-smiley-s3"><span> ;-) </span></span>) and
a, to an "interim BSP" (i.e. a BSP that does not meet all the same
requirements that a "core BSP" does, but would be useful to other users
of its target hardware). The idea is to help lower the barrier of
entry for new users, by providing more choices. The goal is _always_
to migrate an "interim BSP" to full "core BSP" status, as time and
resources permit.<br>
<br>
Again, I understand the magnitude of Ralf's task, and fully appreciate
all his efforts; I certainly don't want to make his job any
harder - at least not without sufficient justification to warrant his
buy-in! Again, I really mean that.<br>
<br>
It seems your suggestion of a "contrib" tree for "interim BSP"
contributions might be all I'm arguing for. I'm not at all sure how it
would work, but the goals seem clear:<br>
1. Provide a repository for as many "interim BSPs" are possible;<br>
2. Provide guidelines for new "interim BSPs"<br>
3. Provide a procedure for migrating "interim BSPs" to full "core
BSP", as interest warrants;<br>
4. Encourage more users of RTEMS, and more contributions to RTEMS;<br>
5. Accomplish the above _without_ violating RTEMS philosophy and
_without_ making Ralf's job any harder!<br>
<br>
Or am I wrong in all this? Should I just leave it all alone?<br>
<br>
Take care,<br>
-Bob<br>
<br>
P.S. Please accept my humble apologies if I've offended anybody, in any
way, and trust that that was, and is, never my intention.<br>
<blockquote cite="mid45E5B4C6.5000005@embedded-brains.de" type="cite">
<pre wrap="">See further comments below.
</pre>
</blockquote>
I agree with all the commentary that follows...<br>
<blockquote cite="mid45E5B4C6.5000005@embedded-brains.de" type="cite">
<pre wrap="">
Robert S. Grimes schrieb:
</pre>
</blockquote>
<blockquote cite="mid45E5B4C6.5000005@embedded-brains.de" type="cite">
<blockquote type="cite">
<pre wrap="">Ralf Corsepius wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I.e. I would probably veto against a driver which is using code from
outside of source tree, because this would render this driver
unbuildable and untestable.
</pre>
</blockquote>
<pre wrap="">Really? Obviously, if the choice was between two existing and working
drivers, Driver A (no external dependencies) or Driver B (depends on
external code), clearly the choice is Driver A. But what about if only
Driver B exists? And, as is the case here, it depends on code that is
provided with the hardware? Would you really want to turn away users of
this platform just because there was no RTEMS-only solution?
</pre>
</blockquote>
<pre wrap=""><!---->
I think the current state of the virtex BSP (or the state for the next
four weeks) will allow it to live outside the RTEMS source tree, e.g. as
a patch that can be applied to the tree. Maybe it could also get placed
into the "contrib" tree on the <a class="moz-txt-link-abbreviated" href="ftp://ftp.rtems.com">ftp.rtems.com</a> server.
</pre>
<blockquote type="cite">
<pre wrap="">Look at it from my (an RTEMS user's) point of view. I've been
campaigning for RTEMS for five years or so, and have finally gotten a
chance to use it. But sadly, no BSP exists for my platform, and my
budget and schedule don't permit developing one. So I have to turn to
something else. In my case, the only reasonable choice, given the
budget and schedule, is to use the vendor-provided software to interface
RTEMS to my hardware, which is what I've been up to. If Xilinx hadn't
provided these drivers, I probably would have had to turn elsewhere.
</pre>
</blockquote>
<pre wrap=""><!---->
Look it another way again: When you start using parts of RTEMS 8say: the
PPC405 CPU support), you would expect to at least have it compilable,
and it should work as expected. If some parts of the RTEMS core
distribution would depend on external packages, you would have to get
them on your own (this is no problem if you have a xilinx EDK) but you
also have to use the proper version used for the initial implementation.
And this might be hard to achive (see the problems I have, because I
have a slightly different EDK version than you have).
</pre>
<blockquote type="cite">
<pre wrap="">An obvious reply is fine, go ahead. There is no problem with my using
RTEMS, adapting a BSP for my target, and using the Xilinx code. Hell,
what I do on my own is my business, right? And sure, that is exactly
what I'm doing. But what I'd like to do, is contribute back to the
RTEMS community, even if only in the smallest of fashion. If I can
provide a BSP that works for a new platform, but it relies on platform
vendor software, isn't that better than nothing? I know that I would
have appreciated such a BSP myself, as a user! It's been a steep climb,
and fortunately external forces have combined to keep me off the
critical path, but I've certainly lost time during this process. Of
course, it's all worth it...
</pre>
</blockquote>
<pre wrap=""><!---->
Robert, you are right here in general. But I am sure it is not SO
difficult to write a TEMAC driver from scratch, and in the long run this
should be our goal. Among others, in the RTEMS community Ralf has the
difficult task to keep the source tree maintainable and therefore he is
the first to stand up, when the source code structure of RTEMS would be
modified to break maintainability.
</pre>
<blockquote type="cite">
<pre wrap="">But isn't there a middle ground here? Can't there be a "user
contributed" BSP class? Wouldn't that be better than a very small
number of publicly-available BSPs? Wouldn't that encourage more users
of RTEMS, a larger community, and ultimately, a better product in the
long run?
</pre>
</blockquote>
<pre wrap=""><!---->
The RTEMS community is smallar than, let's say, the Linux community. But
there your would find the same problems. Any modifications should
integrate into the existing concepts, be compatible with the license,
and should not break maintainability.
But nobody requires that you do all the work. Currently, the virtex BSP
is clearly "work under progress", and obviously the functionality is
there. trust on the potential of the user community and think what is
just happening now: One guy started a work, you improved it, I will add
the new exception handling and Keith (or myself?) will provide a TEMAC
driver that integrates well into the RTEMS tree. It's not the load of
ONE guy to do it all :-)
wkr,
Thomas.
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
rtems-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</a>
<a class="moz-txt-link-freetext" href="http://rtems.rtems.org/mailman/listinfo/rtems-users">http://rtems.rtems.org/mailman/listinfo/rtems-users</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>