Re: [PATCH] powerpc/mm: Allow user space to map rtas_rmo_buf

[Nathan Fontenot <nfont@linux.vnet.ibm.com>]

On 01/22/2016 04:41 AM, Denis Kirjanov wrote:
> On 1/22/16, Michael Ellerman <mpe@ellerman.id.au> wrote:
>> On Fri, 2016-01-22 at 11:58 +0530, Vasant Hegde wrote:
>>> On 01/22/2016 10:59 AM, Michael Ellerman wrote:
>>>> On Thu, 2016-01-21 at 21:45 +0530, Vasant Hegde wrote:
>>>>
>>>>> With commit 90a545e9 (restrict /dev/mem to idle io memory ranges)
>>>>> mapping
>>>>> rtas_rmo_buf from user space is failing. Hence we are not able to make
>>>>> RTAS syscall.
>>>>
>>>> Having said that, why the <expletive deleted> is librtas mapping
>>>> /dev/mem in
>>>> the first place? Unless there is a very good reason, and probably even
>>>> if there
>>>> is, we should fix that to use a sane API.
>>>
>>> We use rtas system call. We use /dev/mem interface to map the RTAS memory
>>> region
>>> (allocated by kernel and information is passed to user space via procfs)
>>> so that
>>> we can read/write to RTAS memory.
>>>
>>> I do not have historical information. May be Nathan has more information
>>> on this.
>>
>> Yeah, we need to dig into what it's actually doing and why. I had a quick
>> look
>> but it wasn't obvious.
>>
>> We should not need 1) a system call, 2) a proc interface, and 3) a mmap of
>> /dev/mem.
>>
>> If the syscall's not sufficient and we really need to mmap, we should create
>> a
>> device which can then be mmapped in a more standard way.
>>
>> Having said that, Nathan's been moving more of the hotplug logic into the
>> kernel, so I'm also not clear on how much of the existing API we will need
>> in
>> the future. So yep hopefully Nathan can chime in.
> 
> Yeah, but if we're going to move to only one interface to work with
> RTAS we can break existing applications.
> 

Yes, but I doubt that anything other than librtas is using this. I don't think
this interface was ever documented anywhere.

-Nathan

>>
>> cheers
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/linuxppc-dev
>