Hi Dmitry, On 6 July 2015 at 19:24, Dmitry Kalinkin <dmitry.kalinkin@xxxxxxxxx> wrote: [...] > > I'm not a VME expert, but it seems that VME windows are a quiet limited resource > no matter how you allocate your resources. Theoretically we could put up to 32 > different boards in a single crate, so there won't be enough windows for each > driver to allocate. That said, there is no way around this when putting together > a really heterogeneous VME system. To overcome such problem, one could > develop a different kernel API that would not provide windows to the > drivers, but > handle reads and writes by reconfiguring windows on the fly, which in turn would > introduce more latency. In my humble opinion using user-space drivers (as workaround for limited windows/images) introduce more latency than let VME driver dynamically configure windows/images. After all VME systems usually aren't so much dynamic by its nature (Who likes continuously put in and out a board which requires an insertion force between 20 and 50 kg?) and are instead heavily used in critical contexts often in non-stop way. In fact this is a big obstacle for adoption of this VME stack (at least for us). We use VME a lot and we care about latency as well so we use only kernel-space drivers for ours VME boards but unfortunately the VME stack let us to link a single board with a single window/image (so max 8 boards on tsi148) only. That said that stack has proven to be very rock solid. Until now we have used a modified version of the old vmelinux.org stack for sharing windows/images between all (ours) VME kernel drivers and we would be very happy to see something similar in vanilla (at least coalescence two adjacent addresses with same modifiers). > Those who need such API are welcome to develop it :) I would be glad to try it if the maintainer is willing to receive this type of changes. Ciao, Alessio _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel