Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp874269pxb; Thu, 25 Feb 2021 18:17:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwuA/+pvQ1VakUs1ZUQuIXxGDvXhZbQpovOC60Fke65WFEPqnMwGtH383USkZLvTK6ywC5l X-Received: by 2002:a05:6402:d1:: with SMTP id i17mr894238edu.85.1614305866266; Thu, 25 Feb 2021 18:17:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1614305866; cv=none; d=google.com; s=arc-20160816; b=zcas65fSCuSo52Sjf5FdQxzRC7nkuhT4RDAetQv1IuyfGFKL7nvl2JjFsLmlF0yQ96 AeP5KI072iXTAFZorsNcjgAizyAabTSmByplCodMhtUJWNuNqCSPPV1Cjt22GkRw7zI1 CaWDba2t97eCfu5kQ+A8PMeKD2N0hqChwqVg7nmtsZQE/ubJ+Wv2ImRTom4hq8MaqxiS Zn4lZDTlYk3ubR1XvMozzpDvXNSmD41Ve7LSzC3s5d5MT2YCjIPcf6A9Gfmym7t4HcoC q0GQ5FH0i2wO04EtcQh8Kx23Z+ZepOknNAF9/K7hL/YZlD8HPvQGC1FhFKeMcaYy4kdl 1Zjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=GuuoejmmAHKXgWprSo5W0XdO3OLbBPSQwwIFvWfIa8A=; b=qVzUzta64Xe/FSH7KPMzcKRbXidBHuqf8wNPK26pSLlfgjVNJwM+/PjWzP38ln1RRj wFwm/lR4OQztLZLX7XyuZfU0GETikdfCIrwaBgoIFbScDPbonmaYnfzHi33ir/5SgvMw ww3ZnZPR6pdHU9jvONb7qn9potILRJd5Lbh1F3RI4hLoRQuMwO1qWm/mcGj13OHM1aJu 1HYUTq82d7jQRs/NV/9kY/rZLZl99Yp1bEKxbtTejeslGMmTCAOfGQlKeHEqy0CChFaZ LkFbYk/qNUrIDhRUd5DHi1xgeN1YXIEaQjZ/rM98b9wUUDWt7s90Jsl7iUFz91fa5Q4m cpNQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w12si4381729edv.389.2021.02.25.18.17.23; Thu, 25 Feb 2021 18:17:46 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230124AbhBZCPE (ORCPT + 99 others); Thu, 25 Feb 2021 21:15:04 -0500 Received: from szxga05-in.huawei.com ([45.249.212.191]:12582 "EHLO szxga05-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229800AbhBZCPC (ORCPT ); Thu, 25 Feb 2021 21:15:02 -0500 Received: from DGGEMS404-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga05-in.huawei.com (SkyGuard) with ESMTP id 4DmtTC6kgVzMf1Q; Fri, 26 Feb 2021 10:12:15 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.204) with Microsoft SMTP Server (TLS) id 14.3.498.0; Fri, 26 Feb 2021 10:14:13 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: compress: Allow modular (de)compression algorithms To: Geert Uytterhoeven , Masahiro Yamada CC: Randy Dunlap , Linux Kbuild mailing list , Linux Kernel Mailing List , , Jaegeuk Kim References: <20210222125916.4168804-1-geert@linux-m68k.org> From: Chao Yu Message-ID: Date: Fri, 26 Feb 2021 10:14:08 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Geert, On 2021/2/23 15:42, Geert Uytterhoeven wrote: >> I checked the code in menu_finalize(), and this seems to work like this. >> >> I discussed the oddity of the select behavior before >> (https://lore.kernel.org/linux-kbuild/e1a6228d-1341-6264-d97a-e2bd52a65c82@infradead.org/), >> but I was not confident about what the right direction was. >> >> >> Anyway, the behavior is obscure from the current code. >> >> If you want to make this more robust, >> you can write as follows: >> >> config F2FS_FS >> tristate "F2FS filesystem support" >> depends on BLOCK >> select NLS >> select CRYPTO >> select CRYPTO_CRC32 >> select F2FS_FS_XATTR if FS_ENCRYPTION >> select FS_ENCRYPTION_ALGS if FS_ENCRYPTION >> select LZO_COMPRESS if F2FS_FS_LZO >> select LZO_DECOMPRESS if F2FS_FS_LZO >> select LZ4_COMPRESS if F2FS_FS_LZ4 >> select LZ4_DECOMPRESS if F2FS_FS_LZ4 >> select LZ4HC_COMPRESS if F2FS_FS_LZ4HC >> select ZSTD_COMPRESS if F2FS_FS_ZSTD >> select ZSTD_DECOMPRESS if F2FS_FS_ZSTD >> >> The code is a bit clumsy, but it is clear >> that the module (F2FS_FS) is selecting the >> compress/decompress libraries. > Actually the above is what I tried first ;-) Works fine. > > Then I started to look for similar cases in other file systems (e.g. > EROFS_FS_ZIP), and discovered the issue doesn't happen there, which > sparked my investigation. So I settled on the direct dependency, > because it keeps all compression-related logic together. It looks above way is more explicit, how about using your previous implementation? Thank, > > Gr{oetje,eeting}s,