[PATCH] pc386: Add virtio network driver

[Jinhyun]

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