On 01/28/2017 01:11 PM, Ahmed Samy wrote:
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...
This email caught me as I was just sitting down to this. A couple days later than I expected, sorry.
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?
heh, I'm sure we're in strong agreement there: good documentation is desirable, yet sometimes
missing. :) As for "what made you think that people use it wrong?", I think Zhong spotted a
potential problem, then (if I understand correctly) decided that it was actually OK, but by then, I
had egged him on to remove the EXPORT, because it looked "off" to me, too. (It still does.)
So I'll take the heat for this one, and that's why I'm following up on it.
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.
Quick question, what do you mean "a function as part of vmalloc"?
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...
Agreed.
thanks,
john h
Thanks,
asamy
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
