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
