Hi, On 19 October 2015 at 11:19, Dmitry Kalinkin <dmitry.kalinkin@xxxxxxxxx> wrote: [...] > There is no optimal solution. In vanilla kernel you have just two drivers. You > can either have 8 GE PIO2 boards or 4 GE PIO2 boards and any amount of boards > potentially accessible through vme_user. None of this provides for the case > when you have a crate with more than 8 GE PIO2 boards in it. Indeed, if you > have built your little proprietary system around one or two drivers so it just > fits using up all of the DMA resources and you somehow still need vme_user, > this patch will surely break it for you. But if we really care about *all* > users then there is no difference in how much resources are used by any driver, > there is always a setup for which they won’t be enough. >> The number of VME windows is limited, so having a user space shim either hog or limit the number of resources available either in kernel space or user space is not an optimal solution. > How vme_user is different from proprietary driver A to deserve such discrimination? > Would it be more optimal if proprietary driver A would take less resources that > could have otherwise been exposed to the userspace? > > I agree that due to the nature of vme_user it should have some knobs to tune > it’s resource consumption, but I don’t think these should be some special ugly > knobs that only a userspace driver gets. The solution could have been to use > same kind of module params as in vme_pio2. But instead of implementing that, I > spent my time unknowingly arguing over whether mainline kernel developers > should be denied breaking certain proprietary systems lurking in the shadow of > the VME subsystem. Wonderful. IMHO VME stack should handle bus resources dynamically not matter from where the requests come from (user-space or kernel-space). Ciao, Alessio _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
