Re: [PATCHv5] staging: vme_user: provide DMA functionality

[Alessio Igor Bogani]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/