[PATCH] pc386: Add virtio network driver

[Joel Sherrill]

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 <gedare at rtems.org> wrote:

> 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
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20160614/74c60d93/attachment-0002.html>