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
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
