[PATCH] pc386: Add virtio network driver

[Gedare Bloom]

Or maybe just the RTEMS_COMPILER_MEMORY_BARRIER()?

On Tue, Jun 14, 2016 at 10:37 AM, Gedare Bloom <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 <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:devel-bounces at rtems.org] On Behalf Of Sebastian Huber
>> Sent: Wednesday, June 01, 2016 2:30 PM
>> To: Chris Johns <chrisj at rtems.org>; 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   : +49 89 189 47 41-16
>> Fax     : +49 89 189 47 41-09
>> E-Mail  : 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
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel