<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 29, 2016 at 7:48 AM, Gedare Bloom <span dir="ltr"><<a href="mailto:gedare@rtems.org" target="_blank">gedare@rtems.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Mar 29, 2016 at 7:51 AM, Sebastian Huber<br>
<<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br>
> On 29/03/16 13:47, Sebastian Huber wrote:<br>
>><br>
>> Not to be committed. How can we fix this?<br>
><br>
><br>
> I was able to run all MP tests except mp14 successfully using Qemu and a<br>
> virtual network. The TCP/IP based MPCI support is basically BSP independent<br>
> and should work for all BSPs that support a network interface driver in the<br>
> old network stack. So, maybe this MPCI driver should move to libchip. I am<br>
> not sure how we should address the confdefs.h issue.<br>
><br>
</span>This makes sense. You could add a new configure flag for the driver<br>
then, e.g. CONFIGURE_MPCI_DRIVER_ENABLED or something to control the<br>
confdefs ++bloat.<br>
<span class=""><br></span></blockquote><div><br></div><div>There is already CONFIGURE_MP_MPCI_TABLE_POINTER which is really</div><div>an older name for what you are suggesting. For consistency, it could be renamed.</div><div><br></div><div>You should have "mpci net" and "mpci shm" and let the bsp.h select. There is</div><div>precedence for bsp.h to set defaults for confdefs.h.  </div><div><br></div><div>Disclaimer: And yes.. the public interface for bsp.h isn't as well defined as we </div><div>would like but I am trying to trim down what's included and start moving things </div><div>to bspimpl.h to get a few examples that are cleaner.</div><div><br></div><div>Wasn't your other configuration issue that you wanted a server thread and</div><div>some resources per core?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> The mp14 test seems to use a global partition. Does this make sense in a<br>
> non-shared memory setup, e.g. message passing via TCP/IP?<br>
><br>
</span>I doubt it makes sense. You need to have a lot of middleware to get a<br>
(partitioned) global address space to work over a message passing<br>
interface. It has been done before e.g. to use UPC/OpenMP over MPI,<br>
but I don't think this is necessarily good in our case.<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>No. It does not make sense. </div><div><br></div><div>Long ago, there was an MPCI implementation over MPI but I personally</div><div>never saw it. I don't know how they dealt with this.</div><div><br></div><div>Thinking generically, I would say we need a way to say global partitions are not</div><div>supported by a particular MPCI. </div><div><br></div><div>FWIW should the "HAS OWN TABLE" support in confdefs.h disappear? I would</div><div>really hope that no one ever writes their own configuration by hand. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">
> --<br>
> Sebastian Huber, embedded brains GmbH<br>
><br>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
> Phone   : <a href="tel:%2B49%2089%20189%2047%2041-16" value="+4989189474116">+49 89 189 47 41-16</a><br>
> Fax     : <a href="tel:%2B49%2089%20189%2047%2041-09" value="+4989189474109">+49 89 189 47 41-09</a><br>
> E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a><br>
> PGP     : Public key available on request.<br>
><br>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
><br>
><br>
> _______________________________________________<br>
> devel mailing list<br>
> <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a></div></div></blockquote></div><br></div></div>