From nobody Tue Jan 31 23:34:33 2023 X-Original-To: dev-commits-src-main@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4P61c10Ns3z3csFJ; Tue, 31 Jan 2023 23:34:41 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4P61c0711Kz42Nn; Tue, 31 Jan 2023 23:34:40 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675208081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kcbbn3VUjz6CKqueKXw33Wvi9iVrU11EqeJsBIkAbkM=; b=EQqXHR58aLazBpVU9S7/nVmd3eEE3ve07fg7SGSrLqEnILMtB4o2hhfuLJZ+bPSKEfWVLY Oy69QODekOOurCs9smBmcZb/COAuWXRETPeuXov6X9fq4bZTBK4EndS+cf/m+rWbpmv0Dz CWBTZqgPC0hiY13E2h9FAZBI/UnXZlyZoFK7GNw4NV7DyFrhEwvt+tl5vdB3TDS8n3bNPi SQcQERYa2k7e8/UN6h/Bk2Cam/GGW5sNudhvCjkOWlNJPm7enB5I+aX1iC2sd1/Mw/rmr6 RLSV9lgL1nfiTme1f0tjbz5Pakt/bFRInI/4Do0FJxi46i33xseXFv8EFOByJw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1675208081; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=kcbbn3VUjz6CKqueKXw33Wvi9iVrU11EqeJsBIkAbkM=; b=lSYDC0Q6PooPRkLPbCOxnXVJdEsaYjCLDfQCDoqHtM7LF11S1oCjklG6zSZmM2A0JcHieH ISuIarPUsWxiFbgDNuK6PwZEwJpyIG6SOl6Z3o6yc1iV+HBWzrweY3PS7SUU3v1dhZyops JSxFh7GoEMjI3Fpi2vQVYTfJCuwP8c+QQPQUFhRy8jCtk9LTa0JIpWAc74FjnBRWFEomIt SrAi3OvMY8W0NvOdnzYG5fSugdxxm3YoO6GIvbnnMHiDanh0Pc8Z4Af/6MB+hV8m38DZKv SaKQEVfMZGc0iVp80sudnDbbGIAv6WF7QQ0c366OJkGlzw9PyC16Ck2d42O1Vw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1675208081; a=rsa-sha256; cv=none; b=MZHYa+r/ErgcmXxJ/wPld1eLBN/Dku7VJnrnl3vOTPGAq/7FPCUl6DIXU5AE94opKJopQS VKh4nI4bjQDiuBs6bmQFUZKTwQjY2Ag893MJKzxY40uqZqkOJRLqH3VFbOX4Gcuvfr4yll um3udXhjqaaitOhUTaVaRKuEeKiFRU1vKn7/eRENXnvoRoN0fIN/cng5NCuhFZAFInxEE6 SMoEwpIZYY29JnA6PgODLKicQa+5Yt2eliOQOL/CXBtNnhV8MfRirReHrbyOv0KbZNqmeN +d6fC6WM+Z+PxAdinJ8xz4cffG1qSnA7v580zl4Y9sk8U4dPG4/rkd5aLnho5Q== Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:13b:39f::9f:25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE Root Certificate Authority" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4P61c04jkWzmsR; Tue, 31 Jan 2023 23:34:40 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 3159A8D4A15D; Tue, 31 Jan 2023 23:34:37 +0000 (UTC) Received: from content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 94E5C5C3A833; Tue, 31 Jan 2023 23:34:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:4902:0:7404:2:1025]) by content-filter.t4-02.sbone.de (content-filter.t4-02.sbone.de [IPv6:fde9:577b:c1a9:4902:0:7404:2:2742]) (amavisd-new, port 10024) with ESMTP id qN4pVnkKskVA; Tue, 31 Jan 2023 23:34:34 +0000 (UTC) Received: from strong-iwl0.sbone.de (strong-iwl0.sbone.de [IPv6:fde9:577b:c1a9:4902:b66b:fcff:fef3:e3d2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 317445C3A830; Tue, 31 Jan 2023 23:34:34 +0000 (UTC) Date: Tue, 31 Jan 2023 23:34:33 +0000 (UTC) From: "Bjoern A. Zeeb" To: =?UTF-8?Q?Jean-S=C3=A9bastien_P=C3=A9dron?= cc: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: Re: git: a83b3ec719eb - main - linuxkpi: list_sort()'s callback now takes list arguments In-Reply-To: <202301312244.30VMiiuF052081@gitrepo.freebsd.org> Message-ID: References: <202301312244.30VMiiuF052081@gitrepo.freebsd.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Commit messages for the main branch of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-main List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-main@freebsd.org X-BeenThere: dev-commits-src-main@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1098556516-898116519-1675208074=:27118" X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1098556516-898116519-1675208074=:27118 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 31 Jan 2023, Jean-Sébastien Pédron wrote: > The branch main has been updated by dumbbell (ports committer): > > URL: https://cgit.FreeBSD.org/src/commit/?id=a83b3ec719eb6c53658656b7b90607564d3c64d3 > > commit a83b3ec719eb6c53658656b7b90607564d3c64d3 > Author: Jean-Sébastien Pédron > AuthorDate: 2023-01-11 22:22:07 +0000 > Commit: Jean-Sébastien Pédron > CommitDate: 2023-01-31 22:36:33 +0000 > > linuxkpi: list_sort()'s callback now takes list arguments Does that description miss a ... takes "const" list ... ? > This change breaks the API of `list_sort()`. `LINUXKPI_VERSION >= 51300` > is used to keep the header compatible with both versions of the > prototype. Given our internals half way through already dal with "const" I see little harm in making it const unconditionally. The actual LINUXKPI_VERSION check probably should be around the DECONST lines in linux_le_cmp() and in list_sort_thunk ; if we really wanted to not lose the "const" half way through for newer versions which are prepared for it. Non-const arguments passed in to list_sort() will still work and we can avoid having an extern with const but an implementation without (not sure why that's not giving warnings anyway). Or am I misreading the change? > Reviewed by: manu > Approved by: manu > Differential Revision: https://reviews.freebsd.org/D38082 > --- > sys/compat/linuxkpi/common/include/linux/list.h | 5 +++++ > 1 file changed, 5 insertions(+) > > diff --git a/sys/compat/linuxkpi/common/include/linux/list.h b/sys/compat/linuxkpi/common/include/linux/list.h > index 80ac57fecf6d..6ec715291807 100644 > --- a/sys/compat/linuxkpi/common/include/linux/list.h > +++ b/sys/compat/linuxkpi/common/include/linux/list.h > @@ -504,7 +504,12 @@ static inline int list_is_last(const struct list_head *list, > (pos) && ({ n = (pos)->member.next; 1; }); \ > pos = hlist_entry_safe(n, typeof(*(pos)), member)) > > +#if defined(LINUXKPI_VERSION) && LINUXKPI_VERSION >= 51300 > +extern void list_sort(void *priv, struct list_head *head, int (*cmp)(void *priv, > + const struct list_head *a, const struct list_head *b)); > +#else > extern void list_sort(void *priv, struct list_head *head, int (*cmp)(void *priv, > struct list_head *a, struct list_head *b)); > +#endif > > #endif /* _LINUXKPI_LINUX_LIST_H_ */ > -- Bjoern A. Zeeb r15:7 --1098556516-898116519-1675208074=:27118--