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 <ged...@rtems.org> wrote: > 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 >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
