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 didnt 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 couldnt 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 Pavels 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-boun...@rtems.org] On Behalf Of Sebastian Huber Sent: Wednesday, June 01, 2016 2:30 PM To: Chris Johns <chr...@rtems.org>; devel@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.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
