On 05.07.2017 06:38, Didier Kryn wrote:

>      Also the API of their driver looked in contradiction with the one 
> of Gabriel Paubert who has been developping a discontinued suite of free 
> VME drivers for Debian. I talked with Gabriel Paubert more than a decade 
> ago because I have been using his driver; it happened that we have 
> completely different views on what VME is made for. 

hmm, never that any VME device on the table ... isn't this just yet
another memory/peripheral bus ? (after a quick look, seems it could
even be driven by gpmc).

I'd imagine it wouldn't take much more than for the usual bus bridges
(pci, gpmc, ...). Don't recall how it was in 2.6 times, but nowadays
this isn't really a big deal. Usually those bridges just map memory
regions to the platform/cpu bus (IOW: cpu potential other busmaster-
capable neighbords can directly access the memory/registers, once
the bridge is set up). Anyways, VME support seems to be mainlined
for quite a long time.

If anybody has some real VME machines, I'd be curious to have closer
look at them.

> Finally, a few years
> ago, a group devised a VME API for Linux every driver has to comply
> with, and Emerson followed the prescription. The API was very similar
> with the one of Paubert, but it also contained some absurdity,

Which absurdities, exactly ?

> and,
> since my project was reaching the end, I just stopped upgrading the
> kernel and staid with version 2.6.27. The machines are still running
> Debian Wheezy with that old kernel.

Well, if there's really no reason to touch the machine at all, it might
be a good idea to leave it as it is. OTOH, there can be many reaons for
upgrading at least some parts of the OS, and then you could get into
trouble w/ that ancient kernel.

I currently have such case w/ much newer devices (Duagon Ionia -
industrial control and daq machines, primarily for railway systems),
Their factory kernel is pretty old and built w/ the hot needle (even
built ontop an hackish TI vendor kernel), and the whole driver stack
for the control/DAQ cards lives entirely in userland (directly polling
on mmap()ed register spaces!), w/ some horribly complex and practically
unmaintainable library (which seems to have a really long history and
even wasn't made for Linux/Unix). As we have to support different HW and
configurations (some customers even have their own boards), we need a
consistent interface -> IIO. And we need newer kernel features, eg.
containers, rt scheduling, etc. So, here I am, reverse engineering the
old stuff and writing a new driver stack on 4.12 ...

>      VME started in the 70's, and it has taken until ~ 5 years ago to 
> have a VME API on Linux. In the mean time users have lived with vendor's 
> BSPs. As a client, I didn't question the reason of all this; I made what 
> I needed to get the job done.

Well, especially in those niches, those vendor BSPs tend to be difficult
(I never use them). Usually, they add proprietary APIs, so you have a
vendor-lockin, their patches tend to be hard to port, and so you're
dependent on their support.

My default approach is moving to mainline kernels and only patch up
what's needed - using the proper kernel infrastructures (eg. IIO for
DAQ devices, instead of proprietary devices).

In the long run, that's (to my experience) way cheaper than coping w/
any vendor BSPs.


--mtx

mit freundlichen Grüßen
--
Enrico, Sohn von Wilfried, a.d.F. Weigelt,
metux IT consulting
+49-151-27565287