> Well if we use a set of valid ranges, then we can start with generic code
> that will set up ranges allowed by the syscall semantics.
>
> Then the arch code could be called with that set of ranges, and perform
> its modifications to that set.
A bit complicated in practice... "set of ranges" ca
Benjamin Herrenschmidt wrote:
Great, this is long overdue for a cleanup.
Indeed... lots of redundant checks, dead code, etc...
I haven't looked at all users of this, but does it make sense to switch
to an API that takes an address range and modifies / filters it? Perhaps
also filling in som
> Great, this is long overdue for a cleanup.
Indeed... lots of redundant checks, dead code, etc...
> I haven't looked at all users of this, but does it make sense to switch
> to an API that takes an address range and modifies / filters it? Perhaps
> also filling in some other annotations (eg. al
Benjamin Herrenschmidt wrote:
!!! This is a first cut, and there are still cleanups to be done in various
areas touched by that code. I also haven't done descriptions yet for the
individual patches.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via the mm
!!! This is a first cut, and there are still cleanups to be done in various
areas touched by that code. I also haven't done descriptions yet for the
individual patches.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via the mm) only when MAP_FIXED is not pas
5 matches
Mail list logo
