Received-SPF: pass (google.com: domain of linux-kernel+bounces-125620-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
References: <20240328064539.95795-1-richard120310@gmail.com>
 <20240328123608.a20ba1260aa9467df9f4256d@linux-foundation.org> <CAH5jb=aY1y19=XAKJG4368Ey6Sq3759euKsWLkLMATO9ac55sw@mail.gmail.com>
In-Reply-To: <CAH5jb=aY1y19=XAKJG4368Ey6Sq3759euKsWLkLMATO9ac55sw@mail.gmail.com>
From: =?UTF-8?B?6YSt5Lul5paw?= <richard120310@gmail.com>
Date: Sat, 30 Mar 2024 16:38:45 +0800
Message-ID: <CAH5jb=b=SXSRQM0YHb0fz5Rt+k1DMfuVQ-Fj+Sa20XrNM+vwqg@mail.gmail.com>
Subject: Re: [PATCH] rbtree: Introduce rb_remove()
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>> We wouldn't merge a change like this unless there are callers of the
>> new function.  Please tell us everything about that.

The last reply didn't follow the requested plain text form, I'm sorry about
 that, again thanks for your patience and time on reviewing my patch.

Best Regards,

I Hsin Cheng.

=E9=84=AD=E4=BB=A5=E6=96=B0 <richard120310@gmail.com> =E6=96=BC 2024=E5=B9=
=B43=E6=9C=8829=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8B=E5=8D=885:10=E5=AF=AB=
=E9=81=93=EF=BC=9A
>>
>> We wouldn't merge a change like this unless there are callers of the
>> new function.  Please tell us everything about that.
>
>
> I see, thanks for your review and the explanation.
>
> Andrew Morton <akpm@linux-foundation.org> =E6=96=BC 2024=E5=B9=B43=E6=9C=
=8829=E6=97=A5 =E9=80=B1=E4=BA=94 =E4=B8=8A=E5=8D=883:36=E5=AF=AB=E9=81=93=
=EF=BC=9A
>>
>> On Thu, 28 Mar 2024 14:45:39 +0800 I Hsin Cheng <richard120310@gmail.com=
> wrote:
>>
>> > Implement the function "rb_remove()", which can perform the removal of=
 a
>> > certain key from the tree. Once the node with the searched key is foun=
d,
>> > we call "rb_erase()" to perform the removal of the node, otherwise the
>> > key doesn't exists in the tree then we return NULL.
>> >
>> > ...
>> >
>>
>> We wouldn't merge a change like this unless there are callers of the
>> new function.  Please tell us everything about that.
>>