RE: Question regarding the usage of devlib2

["Kline, David" <dkline@wolve.com>]

FYI:
I've been using the Linux uio_pci_generic driver for a few months now to exercise
propriety hardware in high-speed trading systems in the finance sector. The
current implementation is Centos 6, EPICS 3.15.5, and synApps 5.8. Using asyn
to access PCIe registers and interface to in-house and commercial IP. EPICS is
employed to primarily serve as a tap into control and status registers, and to
visual them by traders and other clients, as well as pyepics for in-house developed
scripts. All is working very well with the Linux driver, EPICS, pyepics, and asyn, well
worth the effort [and fun]. 

Best
/david kline

> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov <tech-talk-bounces@aps.anl.gov> On
> Behalf Of Michael Davidsaver
> Sent: Friday, May 4, 2018 2:20 PM
> To: Jörn Dreyer <j.dreyer@hzdr.de>
> Cc: tech-talk@aps.anl.gov
> Subject: Re: Question regarding the usage of devlib2
> 
> On 05/04/2018 05:07 AM, Jörn Dreyer wrote:
> > I am currently working on a driver for a PCI card. To access this card
> > I have writen a small uio kernel driver for Linux based on the concept from
> mrfio2.
> 
> Did you see the 'uio_pci_generic' driver which comes with Linux, and my
> 'pci_generic_msi' variant in devlib2?
> 
> > In the asynDriver that I'm working on I use devlib2 to get access to
> > the mapped memory regions of the card following the concept of
> > evrMrmApp from mrfio2.  In mrfCommon a lot of macros (BITSET, BITCLR,
> > READS and WRITE for various bitwidth) are defined.
> 
> Which ones would you find useful?  I didn't port them over because, in
> hindsight I'm not sure they were so helpful to me.
> 
> The original goal was to prevent unintentional access with an incorrect width.
> eg. Using a 32-bit read of a 16-bit register.  In practice with mrfioc2 this was a
> waste.  Due to the strict recipe needed to work with both vme and pci, only
> 32-bit reads could be used.
> 
> Also in hindsight, the BITSET/CLR read-modify-write macros are a recipe for
> race conditions if used without preventing concurrent access (eg. interrupt
> disable or mutex).  This convenience was a little too convenient.
> 
> > Should these macros not be part of devlib2? This way other modules
> > could profit from this work much easier. Pulling these files into my
> > project would require to install the mrfio2 module even if I do not
> > have the hardware. Not thinking about license conflicts that might
> > arise if I copy the code over to my project.
> 
> mrfioc2 uses the same EPICS open license as devlib2, and Base itself.  So I
> don't think that this aspect will make your life more complicated than it
> already is (if you're thinking about licensing).
> 
> > Regards,
> > Jörn Dreyer
> >

------------------------------------------------------------------------------

This message is intended only for the personal and confidential use of the recipients named above. If the reader of this email is not the intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return email and permanently delete the copy you received.

This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. Wolverine is not responsible for any recommendation, solicitation, offer or agreement or any information about any transaction, customer account or account activity that may be attached to or contained in this communication. Wolverine accepts no liability for any content contained in the email, or any errors or omissions arising as a result of e-mail transmission. Any opinions contained in this email constitute the sender's best judgment at this time and are subject to change without notice.