<div dir="ltr">Does the virtio.h file need to be in the BSP or is it independent and can move<div>to shared?</div><div><br></div><div>I am glad to see this code being BSP and architecture independent. :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 14, 2016 at 9:37 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">Or maybe just the RTEMS_COMPILER_MEMORY_BARRIER()?<br>
<div class="HOEnZb"><div class="h5"><br>
On Tue, Jun 14, 2016 at 10:37 AM, Gedare Bloom <<a href="mailto:gedare@rtems.org">gedare@rtems.org</a>> wrote:<br>
> Does _CPU_atomic_Fence() work for you? It is defined in<br>
> cpukit/score/cpu/*/rtems/score/cpuatomic.h<br>
><br>
> On Sat, Jun 11, 2016 at 3:12 AM, Jinhyun <<a href="mailto:jinhyun@konkuk.ac.kr">jinhyun@konkuk.ac.kr</a>> wrote:<br>
>> Hi All,<br>
>><br>
>> Thanks for your comments and suggestions. For a better decision, we like to<br>
>> give a bit of background of our patch.<br>
>><br>
>> Initially, we got a comment from Joel that the pc386 BSP might be a suitable<br>
>> path for our patch as follows:<br>
>> <a href="https://lists.rtems.org/pipermail/devel/2016-March/014157.html" rel="noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2016-March/014157.html</a><br>
>> Though we didn’t discuss more about this issue at that time, he suggested<br>
>> the pc386 path maybe simply because our implementation only worked with<br>
>> pc386. In fact, however, most of our codes are architecture-independent, but<br>
>> the codes for memory barrier are troublesome. If there are<br>
>> architecture-independent wrapper functions for memory barrier in RTEMS, we<br>
>> can simply avoid the architecture dependency by exploiting those. However,<br>
>> we couldn’t find such wrapper functions; thus, our patch includes few lines<br>
>> of assembly instructions of pc386. Now we are working on memory barrier for<br>
>> Sparc. Please let us know if we are missing something here.<br>
>><br>
>> Based on Pavel’s suggestions, we think that the files of our patch can be<br>
>> placed as follows:<br>
>> libbsp/i386/pc386/virtio: virtio.h<br>
>> libbsp/shared: virtio.c, virtio_pci.c, virtio_pci.h, virtqueue.c,<br>
>> virtqueue.h, virtio_ring.h<br>
>> libchip/network: if_vtnet.c, if_vtnetvar.h, virtio_net.h<br>
>> However, in FreeBSD, all files to implement virtio are placed in the same<br>
>> directory, sys/dev/virtio.<br>
>><br>
>> In addition, we are not familiar with libbsd yet. Thus, if our patch can be<br>
>> included in the mainline, it will be easier to continuously contribute to<br>
>> the virtio implementation from our side.<br>
>><br>
>> Jin-Hyun<br>
>><br>
>> -----Original Message-----<br>
>> From: devel [mailto:<a href="mailto:devel-bounces@rtems.org">devel-bounces@rtems.org</a>] On Behalf Of Sebastian Huber<br>
>> Sent: Wednesday, June 01, 2016 2:30 PM<br>
>> To: Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>>; <a href="mailto:devel@rtems.org">devel@rtems.org</a><br>
>> Subject: Re: [PATCH] pc386: Add virtio network driver<br>
>><br>
>><br>
>><br>
>><br>
>> On 01/06/16 06:42, Chris Johns wrote:<br>
>>>> The RTEMS driver infrastructure is not capable enough to deal with a<br>
>>>> plug-and-play architecture like x86.<br>
>>><br>
>>> This does not make sense to me and I fail to see how it relates to the<br>
>>> previous statement. The original classic API for RTEMS is based on a<br>
>>> VME bus standard and while not a hot swap bus architecture it did<br>
>>> allow a plug in architecture based on a huge range of slave boards.<br>
>>> The fact an architecture or bus has plug-and-play support does not<br>
>>> mean RTEMS has to provide such support nor a BSP has reached a dead<br>
>>> end because it does not.<br>
>><br>
>> The standard RTEMS driver infrastructure offers no support for<br>
>> auto-configuration, power-management, hot-plug and so on. The FreeBSD newbus<br>
>> infrastructure offers all of this. I don't think it make sense to add or<br>
>> event develop on our own such a functionality on a per-BSP basis.<br>
>><br>
>> --<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>
>> 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>
>><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>