On 11.07.2017 19:07, Didier Kryn wrote:

> 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.

Can't judge your individual use case and how well the system is secured.
But I'm doing a lot in industrial/embedded area, and it's really
horrible how careless people are here, and how fragile even critical
systems (even cards, rail trains, power distribution, etc), so I'm
even more careful and paranoid.

In my current use case, the proprietary / hw specific userland stuff
is also a massive pain for application development, as we have to
support different hw, and vendors come around with their own proprietary
hackish APIs, instead of just providing proper IIO drivers (that's what
I'm doing right now).

> We don't fear malevolent actions, and, IMHO, safety is
> better granted by an Ada library than by any driver written in C.

Indeed, ADA can be helpful for critical applications - assuming you
have developers speaking that relatively unknown language.
But when it comes to security and stability, there're things that
only the kernel can do properly (unless to do ugly hacks)

>> What exactly is so complex about that ? Smells like a typical task
>> for IIO to me.
>

>      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. 

I'm not sure how well IIO supports userland skipping buffers/sample
ranges, w/o the driver having to read them from the device - shouldn't
be a big deal (likely via lseek). Didn't have that usecase yet (just the
opposite - userland needs to know when device/driver missed samples)

> The VME master (the single-board computer) monitors the status of buffers
> and must free them before the digitizers can overwrite them.

You're lucky ;-)
I just had a hard time explaining my client's indian supplier to
implement something like that (well, let's see how it really looks
when we finally have the hw ;-))

> Before data transfer, the range of samples from the selected channels
> arre 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).

As said above, comes down to whether IIO already allows the client to
specify the sample ranges before the driver actually fetches them,
or that still has to be added.

>      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). 

IIRC, IIO already has logic for that. But I haven't looked at that
in detail.

>      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.

If you're retired anyways, and they're looking for somebody to take
over, feel free to send 'em my contact ;-)

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

who cares about boring web servers ? ;-)


--mtx