From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 910B6533D6 for ; Wed, 29 Jul 2026 04:50:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785300604; cv=none; b=EvKvsfkVBPukqBlYqwEhFXo5spkMCbTc3cXJdR5to0EYY1QrK3Ew18JQR3G85V7+xctZSyiC8+8J6NlI3rAddTTmsos/XtVKr7EQog7T1wYdKe6IzZH8X4hVRebxHFaangx/TB0h0DomLr3IVnA3r7PljcrBWff4g0uTUx0yyLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785300604; c=relaxed/simple; bh=SJzilvlcJHcTHqGyliveyZnTHMFGNELamBtaiVkxn2k=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=gDxL9w0XOT1xz9cpIIB3krPRZFv5DhlI7P1cBhBJE5XBLrT4tsv3v59yw4iG5s3Im/Cb71qN8D01+ILEcVhVqNXvZQscZmrYhCx8D/v91S6wCfE4qwYv4QCQ3gaGNjRUYQuPnXXaEe7wTZwlnkzN3f9LXgGj2vKHJNKCR/4YwWA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=PrNaLLki; arc=none smtp.client-ip=209.85.210.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=chromium.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b="PrNaLLki" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-84a652535dcso362012b3a.3 for ; Tue, 28 Jul 2026 21:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; t=1785300603; x=1785905403; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=qfToxm6QEw8mqwMRQS66uT/M13nI1gMKV9iwpsUtdmw=; b=PrNaLLkimMpnwZxfwJjE2fY1EsZZszXOLeBYa3y3IZun4yyChr2ZoZEjbdyN84iqPe 9hqw/yvXmbvLZY15rrmBFEjNgX+Yeplu1HEIYnQRH0s9c+xdaQCNKXtwZ1AvnWHuRPLJ sJ1NlZ+uY8wejD6IbCCG3pDmmOjGB7lqAopa4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785300603; x=1785905403; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=qfToxm6QEw8mqwMRQS66uT/M13nI1gMKV9iwpsUtdmw=; b=RYnjevSze8HNqt8NSdiBLWWPt114F2NVxczEVBV8vLMJ4jaVCrygCafLFfiPFxfLSu GeeU9aVP3OOVO6/OcEn2VoV3zBLCIf/CMTspyPYlIs9lU/GLduEjVFXGo9GLcrMliuWQ Ac9wTzTiqiPgw3FlNFW7Cv/jlCLuuyOPtptNKXKqCQO7a4+OnhTCzb03xnJoGNXlp/cQ KMKBk/+hxE8HMuStvtq2/BQD8aMZU6NVvSe7Z0mSRQegV9fXJmd7YxkZd8U1qYJe0yWI MqxDVVpAAFc0kD8e7176DSuQDJj1Y2bvHowxnU07vIS4S+KMo6mhzNdsfdRA+6MC2EJs K3/w== X-Forwarded-Encrypted: i=1; AHgh+RrdN3131yh1oJqMpOpDJe6hmKbbUZFzs4jlKcLSkSyhA0RhcjaaW6GX7OhclA10sWCh2CPHLNa6xLmIAK0=@vger.kernel.org X-Gm-Message-State: AOJu0YwaEGVNq8dkzoWvtNnPRD/nHV7DJd+52muJyQgLfbjW9XmTGl5X HWQYLHjQnznb6s2gw8r8fizT8RV+Wd/l6CTSZnJ2ph/JSoArUdXEcPs85I8JARUPfg== X-Gm-Gg: AR+sD12c06QdJMUqoIL/9K1hOnPifEogKz1os9zsQodw9eX3ylFM7dH0jkH3vcVtj+s 6Smf8EilORGEI0OU58pt2aKMiq2QFubo6RQRf8a9RmFtUDnAQfc88FsAAgg8tRfIjGIGDVS+0Vo /8f7TtswybAZDIHvXg+wGojU2Gju2lhl0N7s6yM0k5VlbPdSCOCJUPQg+Gtjil/bHWDDKR9/eMt ez1xlRR7y+kHZaBxeOqfc2iWXX6h0gYy+dkt+YvI7bEgCZcsY0v/os9KjqO+0KeX9mj17xsNznu 4LYNWqv38ZwnpHfHNRzqDdwOcacnHB5z+4GgYPgYN1abWy/ytfDJgO5gcCdDR1mBTG9hcpj2D2G oliiStHHefBvqMc+bFIel8xzc256RM3PUXQUUWB5P/2cjmDa9sBFETSautsf0RRrRPZR8ys5O/8 nR9qPFHeb999/QhILq/kuZSa0aOWKUuUEzdpruR/Y6dMkaTq3BND5xSlIViqw8mjCUYn2hrx6ih oADssg85WwJu3FF5H9gVU3TzkKO X-Received: by 2002:a05:6a00:10ca:b0:848:2a55:7110 with SMTP id d2e1a72fcca58-84e932ed557mr5142666b3a.36.1785300602949; Tue, 28 Jul 2026 21:50:02 -0700 (PDT) Received: from google.com ([2a00:79e0:2031:6:65c1:52a3:f6d3:37dc]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-84ea7344ca8sm260156b3a.21.2026.07.28.21.50.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Jul 2026 21:50:02 -0700 (PDT) Date: Wed, 29 Jul 2026 13:49:58 +0900 From: Sergey Senozhatsky To: haoqin huang Cc: Sergey Senozhatsky , Minchan Kim , Jens Axboe , Nick Terrell , David Sterba , Andrew Morton , linux-kernel@vger.kernel.org, linux-block@vger.kernel.org, Haoqin Huang , Rongwei Wang Subject: Re: [PATCH v2 3/5] zstd: move ZSTD_MAX_CLEVEL to zstd_lib.h Message-ID: References: <20260627070216.13511-1-haoqinhuang7@gmail.com> <20260728092935.31139-1-haoqinhuang7@gmail.com> <20260728092935.31139-3-haoqinhuang7@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On (26/07/29 12:32), haoqin huang wrote: > > > > > -#define ZSTD_MAX_CLEVEL 22 > > > > > - > > > > > __attribute__((__unused__)) > > > > > > > > Sashiko made a good point. Can we use zstd_max_clevel() instead? > > > > > > Good point, I'll drop this patch and use zstd_max_clevel() instead > > > in v3. > > > > > > Since it's a runtime function and can't be used for static struct > > > initialization, I plan to set backend_zstd's level_max to -1 as a > > > sentinel value, and query the actual maximum in > > > zcomp_validate_params(): > > > > > > s32 max = backend->level_max; > > > if (max < 0) > > > max = zstd_max_clevel(); > > > > > > Do you think this approach is feasible? > > > > Hmm, no, that doesn't look good. zcomp should not include > > zstd.h or any other libs directly. Should params validation > > be a per-backend callback then? > > Good point, zcomp.c shouldn't include library headers. A per-backend > callback would be cleaner. > > I'll add an optional validate_params to zcomp_ops: the zstd backend > implements it using zstd_max_clevel() internally, while lzo/deflate > and others just rely on the static caps check (no callback needed). > zcomp.c stays free of any library headers. I'm actually leaning towards validation in .setup_params() now. It's not immediate but, first, it doesn't matter that much, we still don't create zram with invalid params configuration and, second, it sort of makes sense to do validation in .setup_params(). We already started doing that for deflate winbits (a patch from earlier today). Can you please add your validation to per-backend .setup_params()?