Or maybe just the RTEMS_COMPILER_MEMORY_BARRIER()?
On Tue, Jun 14, 2016 at 10:37 AM, Gedare Bloom <ged...@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 <jinh...@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-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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
