Is xilinx source code license ok with rtems?

Wed Feb 28 16:58:46 UTC 2007

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.

See further comments below.

Robert S. Grimes schrieb:
> Ralf Corsepius wrote:
>> 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.
>>   
> 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?

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 ftp.rtems.com server.

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

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

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.

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

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.

> 
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users

-- 
--------------------------------------------
embedded brains GmbH
Thomas Doerfler           Obere Lagerstr. 30
D-82178 Puchheim          Germany
Tel. : +49-89-18 90 80 79-2
Fax  : +49-89-18 90 80 79-9
email: Thomas.Doerfler at embedded-brains.de
PGP public key available on request