[PATCH] pc386: Add virtio network driver

[Jinhyun]

Thanks for the comments.
We are trying to either use the compiler memory barrier as you people suggested or simply define the variables as volatile.
We plan to repost the revised patch in a week.
 
Since new patch would be no longer architecture-independent, we are thinking to locate the files at c/src/lib/ilbbsp/shared/.
Hope this makes sense.
 
Thanks,
Jin-Hyun

From: Joel Sherrill [mailto:joel at rtems.org] 
Sent: Tuesday, June 14, 2016 11:55 PM
To: Gedare Bloom <gedare at rtems.org>
Cc: Jinhyun <jinhyun at konkuk.ac.kr>; jinh at konkuk.ac.kr; devel at rtems.org
Subject: Re: [PATCH] pc386: Add virtio network driver

Does the virtio.h file need to be in the BSP or is it independent and can move
to shared?

I am glad to see this code being BSP and architecture independent. :)

On Tue, Jun 14, 2016 at 9:37 AM, Gedare Bloom <mailto:gedare at rtems.org> wrote:
Or maybe just the RTEMS_COMPILER_MEMORY_BARRIER()?

On Tue, Jun 14, 2016 at 10:37 AM, Gedare Bloom <mailto:gedare at rtems.org> wrote:
> Does _CPU_atomic_Fence() work for you? It is defined in
> cpukit/score/cpu/*/rtems/score/cpuatomic.h
>
> On Sat, Jun 11, 2016 at 3:12 AM, Jinhyun <mailto:jinhyun at konkuk.ac.kr> wrote:
>> Hi All,
>>
>> Thanks for your comments and suggestions. For a better decision, we like to
>> give a bit of background of our patch.
>>
>> Initially, we got a comment from Joel that the pc386 BSP might be a suitable
>> path for our patch as follows:
>> https://lists.rtems.org/pipermail/devel/2016-March/014157.html
>> Though we didn’t discuss more about this issue at that time, he suggested
>> the pc386 path maybe simply because our implementation only worked with
>> pc386. In fact, however, most of our codes are architecture-independent, but
>> the codes for memory barrier are troublesome. If there are
>> architecture-independent wrapper functions for memory barrier in RTEMS, we
>> can simply avoid the architecture dependency by exploiting those. However,
>> we couldn’t find such wrapper functions; thus, our patch includes few lines
>> of assembly instructions of pc386. Now we are working on memory barrier for
>> Sparc. Please let us know if we are missing something here.
>>
>> Based on Pavel’s suggestions, we think that the files of our patch can be
>> placed as follows:
>> libbsp/i386/pc386/virtio: virtio.h
>> libbsp/shared: virtio.c, virtio_pci.c, virtio_pci.h, virtqueue.c,
>> virtqueue.h, virtio_ring.h
>> libchip/network: if_vtnet.c, if_vtnetvar.h, virtio_net.h
>> However, in FreeBSD, all files to implement virtio are placed in the same
>> directory, sys/dev/virtio.
>>
>> In addition, we are not familiar with libbsd yet. Thus, if our patch can be
>> included in the mainline, it will be easier to continuously contribute to
>> the virtio implementation from our side.
>>
>> Jin-Hyun
>>
>> -----Original Message-----
>> From: devel [mailto:mailto:devel-bounces at rtems.org] On Behalf Of Sebastian Huber
>> Sent: Wednesday, June 01, 2016 2:30 PM
>> To: Chris Johns <mailto:chrisj at rtems.org>; mailto:devel at rtems.org
>> Subject: Re: [PATCH] pc386: Add virtio network driver
>>
>>
>>
>>
>> On 01/06/16 06:42, Chris Johns wrote:
>>>> The RTEMS driver infrastructure is not capable enough to deal with a
>>>> plug-and-play architecture like x86.
>>>
>>> This does not make sense to me and I fail to see how it relates to the
>>> previous statement. The original classic API for RTEMS is based on a
>>> VME bus standard and while not a hot swap bus architecture it did
>>> allow a plug in architecture based on a huge range of slave boards.
>>> The fact an architecture or bus has plug-and-play support does not
>>> mean RTEMS has to provide such support nor a BSP has reached a dead
>>> end because it does not.
>>
>> The standard RTEMS driver infrastructure offers no support for
>> auto-configuration, power-management, hot-plug and so on. The FreeBSD newbus
>> infrastructure offers all of this. I don't think it make sense to add or
>> event develop on our own such a functionality on a per-BSP basis.
>>
>> --
>> Sebastian Huber, embedded brains GmbH
>>
>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>> Phone   : tel:%2B49%2089%20189%2047%2041-16
>> Fax     : tel:%2B49%2089%20189%2047%2041-09
>> E-Mail  : mailto:sebastian.huber at embedded-brains.de
>> PGP     : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>
>> _______________________________________________
>> devel mailing list
>> mailto:devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> mailto:devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
mailto:devel at rtems.org
http://lists.rtems.org/mailman/listinfo/devel