Re: ioremap_page_range: remapping of physical RAM ranges

[Ahmed Samy <f.fallen45@gmail.com>]

On Thu, Jan 26, 2017 at 12:33:02AM -0800, John Hubbard wrote:
> 
> That's ioremap_page_range, I assume (rather than remap_page_range)?
> 
> Overall, the remap_ram_range approach looks reasonable to me so far. I'll
> look into the details tomorrow.
> 
> I'm sure that most people on this list already know this, but...could you
> say a few more words about how remapping system ram is used, why it's a good
> thing and not a bad thing? :)
> 
> thanks
> john h
> 
Please let me know if you're going to actually make a commit that either
	1) reverts that commit
	2) implements a "separate" function...

Either way, I don't think the un-export is reasonable in the slightest, if that
function is too low-level, then why not also un-export pmd_offset(),
pgd_offset(), perhaps current task too?  These interact directly with low-level
stuff, not meant for drivers, the function is meant to be low-level, I don't know
what made you think that people use it wrong?  How about writing proper
documentation about it instead?  Besides, even if that function does not exist,
you can always iterate the PTEs and set the physical address, it is not hard,
but the safe way is via the kernel knowledge, which is what that function
when combined with others (from vmalloc) provide...

How about this, a function as part of vmalloc, that says something like
`void *vremap(unsigned long phys, unsigned long size, unsigned long flags);`?
Then that solved the problem and there is no need for "low level" functions,
anymore.

Other than, if you're not going to apply a proper workaround, then let me know,
and I'll handle it myself from here.  I don't want this to get past the next
-rc release, so please let's get this fixed...

Thanks,
	asamy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>