On Wed, Feb 14, 2024 at 12:53:42PM -0800, Alexei Starovoitov wrote: > On Wed, Feb 14, 2024 at 12:36 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > > > NAK. Please > > What is the alternative? > Remember, maintainers cannot tell developers "go away". > They must suggest a different path. That criteria is something you've made up. Telling that something is not ok is the most important job of not just maintainers but all developers. Maybe start with a description of the problem you're solving and why you think it matters and needs different APIs. > . get_vm_area - external > . free_vm_area - EXPORT_SYMBOL_GPL > . vunmap_range - external > . vmalloc_to_page - EXPORT_SYMBOL > . apply_to_page_range - EXPORT_SYMBOL_GPL > > and the last one is pretty much equivalent to vmap_pages_range, > hence I'm surprised by push back to make vmap_pages_range available to bpf. And the last we've been trying to get rid of by ages because we don't want random modules to > > > For example, there is the public ioremap_page_range(), which is used > > > to map device memory into addressable kernel space. > > > > It's not really public. It's a helper for the ioremap implementation > > which really should not be arch specific to start with and are in > > the process of beeing consolidatd into common code. > > Any link to such consolidation of ioremap ? I couldn't find one. Second hit on google: https://lore.kernel.org/lkml/20230609075528.9390-1-bhe@xxxxxxxxxx/T/ > I surely don't want bpf_arena to cause headaches to mm folks. > > Anyway, ioremap_page_range() was just an example. > I could have used vmap() as an equivalent example. > vmap is EXPORT_SYMBOL, btw. vmap is a good well defined API. vmap_pages_range is not. > What bpf_arena needs is pretty much vmap(), but instead of > allocating all pages in advance, allocate them and insert on demand. So propose an API that does that instead of exposing random low-level details.
