devLib ruminations

["Davidsaver, Michael" <mdavidsaver@bnl.gov>]

All, 

Some thoughts

1) No 'virtual os' table behind the devLib PCI api.

2) A question: Should devLib support the possibility of multiple VME
bridges/busses on one host?

Yes) The 'virtual os' table would become the 'bus operations' table.
Each bus would have its own.  There would be an api for adding buses at
runtime.

No) The 'virtual os' table goes away completely.  A null version of
devLibOSD would go into src/libCom/osi/os/default/.

3) Add callback hooks for some specific operations.  This could be used
for BSP specific quirks.  Before and after read/write probing would be
one example.


So far I have been working with the 'virtual os' table concept.  I have
been in contact with Graham Waters of TRIUMF about their use of Linux
with devLib.  It looks like a straight forward piece of code which wraps
a vendor provided library for the Universe2.  It is not designed to
insert itself at runtime.

I have begun to wonder about the wisdom of maintaining the 'virtual os'
plugin interface when there is only one plugin for it.  This is
especially true for the PCI interface.  Both RTEMS and VxWorks have one
uniform complete interface for PCI access, and Linux has none (for
userspace).

The one place where the 'virtual os' table would be necessary is when
one system has multiple PCI-to-VME bridges from different vendors.  This
might be the case if there was a PMC card version of the SIS PCI-to-VME
bridge, and I put one on an MVME5500.  This wouldn't even be a necessity
for multiple bridges from the same vendor (say 4 SIS cards in a Linux
box).

Of course, this is a non-issue unless the devLib VME api recognizes the
possibility of having more than one VME bridge.  This would mean
changing the signatures of all VME functions to take an extra argument
to identify which bus was being referred to.  So a particular VME
register would be identified by the triplet bus/space/address.

However, most people will only deal with systems having a single VME
bridge (bus #0).  The question is if it is worthwhile to change the api
for a corner case?


I look forward to hearing your thoughts.

Michael Davidsaver