it seems your patch is later then mine? you rejected mine patch and then committed yours? I can't understand....
------------------origin------------------ from：Burakov,Anatoly <anatoly.bura...@intel.com> to：David Marchand <david.march...@redhat.com>; copy：han.li1;Thomas Monjalon <tho...@monjalon.net>;dev <dev@dpdk.org>; date ：2019/10/24 20:39 title ：Re: [dpdk-dev] [PATCH v3] lib/librte_eal/linuxapp: fix runtime configmmap issue On 24-Oct-19 1:22 PM, Burakov, Anatoly wrote: > On 24-Oct-19 12:23 PM, David Marchand wrote: >> On Thu, Oct 24, 2019 at 1:14 PM Burakov, Anatoly >> <anatoly.bura...@intel.com> wrote: >>> >>> On 24-Oct-19 8:37 AM, David Marchand wrote: >>>> On Wed, Oct 23, 2019 at 7:47 PM Burakov, Anatoly >>>> <anatoly.bura...@intel.com> wrote: >>>>> >>>>> On 23-Oct-19 11:42 AM, Li Han wrote: >>>>>> In rte_eal_config_reattach(),the secondary mmap may fail >>>>>> due to the rte_mem_cfg_addr already be used by others.do >>>>>> the change just as the rte_fbarray_init() do.if no >>>>>> base_virtaddr,use the default 0x100000000. >>>>>> >>>>>> v2/v3: >>>>>> -fix code style issues >>>>>> >>>>>> Signed-off-by: Li Han <han....@zte.com.cn> >>>>>> --- >>>>> >>>>> Nack. There's a reason why we map it at the same address, and it's to >>>>> have all pointers working across processes. Remapping it at a >>>>> different >>>>> address has potential to break things. >>>> >>>> Marked as rejected. >>>> Thanks. >>>> >>> >>> Hi David, >>> >>> My apologies, I've misinterpreted the intent of the patch. I am >>> rescinding my NACK. >> >> Ok, I will put it back in my queue. >> No conflict with the work on >> http://patchwork.dpdk.org/project/dpdk/list/?series=5854 ? >> There was a comment by Stephen, btw. >> > > Oh, i forgot about that patchset... > > Yes, it seems to be doing the same thing, but in a more general way > (because i was actually fixing an issue on FreeBSD...). Let me get back > to you on this. > Yes, that patch is a superset of this one, so this can be discarded, i think. Apologies for the back and forth. -- Thanks, Anatoly
