The system isn't a server open to the public. It's a kind of 
industrial process (though it's for fundamental research). Only a 
limited number of users have an account on the hosts and only members of 
the vme group are given permission to access the devices associated to 
VME. In production, only one user runs a few applications (essentially 
one), some automatically on reboots and some under remote control. A 
whole library written in Ada comes between the applications and the 
driver; it adds a sufficient level of abstraction and a few facilities 
and takes care of safety controls. The applications are all written in 
Ada, of course. We don't fear malevolent actions, and, IMHO, safety is 
better granted by an Ada library than by any driver written in C.

     The waveform digitizers boards have 8 channels of 8-bit 500MSPS 
flash-ADCs, each with 1024 buffers of 4096 bytes (samples). The 
(external) trigger comes after the data has been recorded; the many 
buffers grant asynchronism between data taking and read-out. The VME 
master can skip buffers (events) or read them, totally or partially. The 
VME master (the single-board computer) monitors the status of buffers 
and must free them before the digitizers can overwrite them. Before data 
transfer, the range of samples from the selected channels are arranged 
into a special buffer of the WFD boards, following detailed instructions 
from the VME master, before they are transferred using the 2eSST320 
protocol (currently the fastest VME64x protocol). The amount of data 
transferred for each buffer depends on external conditions comming from 
a 16-bit binary input present on each board and part of meta-data 
associated to each trigger; the VME master decides what to do based on 
metadata assembled from 4 WFD boards. These metadata are generated by a 
set of very fast measurements associated to the triggering system 
(another subsystem of our set-up).

     It's a little more complicated, as explained above :-)

>>> Which absurdities, exactly ?
>>      Bus errors were not reported to the application but instead 
>> caused a message to syslog! This makes it hard to use; or your 
>> application should monitor the log files!

>>      This isn't the case here. AFAIU, their BSP contains a VME driver 
>> and a device tree. I think it's all GPL. Their buzyness is to send 
>> hardware and they make sure their clients can use it.

>>      These are SBCs with everything soldered: VME, flash memory, 
>> UARTs, USB hub, Sata controllers, Ethernet ports etc... And you just 
>> plug it into a VME crate. It makes no sense to develop a board like 
>> this to use a dozen of them. We made the digitizers and it was 
>> already a big deal for our small team.

>>      Could you develop what is IIO for DAQ devices? 

     We have two detectors running. On each of them, a sophisticated 
trigger logic decides when interesting data has been seen and triggers 
400 channels of waveform digitizers (like 400 synchronous oscilloscope 
channels). 64 bit of trigger-related meta-data are transmitted to the 
read-out subsystem by the trigger system via the waveform digitizers 
digital input. There are a few hundreds triggers per second. The data 
are collected from 5 VME masters (in 5 VME64x crates) through 1gb/s 
ethernet by a Dell Poweredge server, re-arranged, compressed and written 
to disk before further transmission to a big computer center. 
Compression must be done before writing to avoid saturate the disk 
bandwidth.

     I think what I would do now would be to mmap() the VME bridge from 
userspace right away (I've read it's possible with /dev/mem). This way 
it would work with any kernel release and the API wouldn't change. But 
it's too late now, the project will finish by the end of the year and 
I'm retired.

     Sorry, this thread is pretty off-topic, but it reminds that Linux 
isn't only used on web servers :-)

     Didier