Customizing UIO mmap'ing

[Kenneth Adam Miller]

On Fri, Dec 18, 2015 at 9:20 AM, Henry Gomersall <
henry.gomersall at smartacoustics.co.uk> wrote:

> On 18/12/15 14:15, Kenneth Adam Miller wrote:
>
>
> On Fri, Dec 18, 2015 at 7:05 AM, Henry Gomersall <
> henry.gomersall at smartacoustics.co.uk> wrote:
>
>> On 17/12/15 21:35, Kenneth Adam Miller wrote:
>>
>> Generally uio_dmem_genirq.c builds on top of uio.c, which provides a
>> common module basis for isolating code common to the other specific
>> modules. But for a specific purpose, uio_dmem_genirq.c has be either
>> customized or extended in order that specific memory regions can be set as
>> accessible. Most easily, this is done in a first come first serve approach
>> by filling out the details (which exactly?) left missing in
>> uio_dmem_genirq.c, and to start, that would be in uio_of_genirq_match
>> <https://proxy-us.hide.me/go.php?u=zWvu%2Fc4k0RUgdQesK%2F26T4EuwcXktyOuOa%2F3x1F0nLo5r0d9WlQEzfN928BYniutwGWnnJXkaBWcsA6D&b=29>
>> .
>>
>> Am I correct?
>>
>>
>> It's not always necessary to modify uio_dmem_genirq.
>>
>>
> Is it correct though, that I can use another module to stack on top of
> uio_dmem_genirq, and that the correct thing to modify is in fact the
> variable I mentioned?
>
>
> I don't know the answer to this. I'm pretty new to it myself :)
>

Well for any other readers of this conversation, compared to my previous
(perceived) requirements, I now only need to mmap a specific region of
hardware addresses - nothing about custom allocation within that region. I
can use /dev/mem, but that's perceived to be a potential security issue
that we want to keep mitigated. So, we have decided that a uio driver that
filters for the specific hardware address regions that we allow is
desirable. I think that uio_dmem_genirq would be the way to go about it,
but I am not sure there is any example that exists demonstrating how to
edit and then use it.


>
>
> Henry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20151218/d0db70a9/attachment.html