[PATCH] pc386: Add virtio network driver

[Gedare Bloom]

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