From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 80085C433E0 for ; Thu, 18 Mar 2021 00:16:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 234C264F26 for ; Thu, 18 Mar 2021 00:16:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229934AbhCRAPk (ORCPT ); Wed, 17 Mar 2021 20:15:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229562AbhCRAPW (ORCPT ); Wed, 17 Mar 2021 20:15:22 -0400 Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D67BFC06174A for ; Wed, 17 Mar 2021 17:15:21 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id h25so279741pgm.3 for ; Wed, 17 Mar 2021 17:15:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:message-id:from:to:cc:subject:in-reply-to:references :user-agent:mime-version; bh=A5FghKE6j+n2hWOTxyZ9n8jVkns8KT6VJ9efkKaRMAE=; b=YQ7ujubNQeiu4pvlHyWlYLnkQhqSK7m94IJyPlCDZIGxA3uEJnagPGjHPhVkW9Ylw6 wHq8hvWBFTOWzMT7YM7HFJZPquCALdTtCus1JU326F9J1K9aPs3TNAz/pP3+qbj/k6qL X2IE6NmobBe+QO50ugSQFUHVsGROblCNBDSzj+/uvN7YGgJxlxxJDik0UCvTX6Shh+cL J2h4TJTZsKTuAIMfBinxy+VycKmO5u9FrT3Qnf4zeunYgUhDIwKvWhTCBF3mYy6xzL1H roxKSNMrP8832JgIIa+CZMAp0zbkiMjm8LLHp8EHNwhQ477zRFi5NDQbXyf4DXAFYsMT f9Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:from:to:cc:subject:in-reply-to :references:user-agent:mime-version; bh=A5FghKE6j+n2hWOTxyZ9n8jVkns8KT6VJ9efkKaRMAE=; b=O7ei5gYLTegxWd7sp4QVsG5dTpkAFXcY/6DztgqMamdWhY3AB6j8ZHX0kSc1YR3+Fg VoV7PWc/xmPSZk6IrM4CAR06xJZ+f0n5gZ4Yr1IDDl0jjARCp3KIhwGR+v1WrSZwJu/b CrnaWQBD1MW4zJQVR9L9ByLN+tZUU2k09GFr+9j2xDSxMUPc0JVkafWij3mokax+q8pT +yk1tPWmiZS5EBn6J+fYcEvpm7jYiPVf9kn0NXsIK+IxlsLu1dbc2PJVcDZvUO4Q3g2T AZd/e+OKLAPJz27yIB7eztveyCnvwd8ABw8GC4KvBmF0Rf66n1AnjfK8bNsC2R43BM6D VXaA== X-Gm-Message-State: AOAM5326GwpfSWm1lrJsmGX0uCLpd6KWkPnrAYAfdCBdyPsFdzguE1Q4 3jtBFj+KPyylX2ZoILNMO6U= X-Google-Smtp-Source: ABdhPJwfHK/QGtbq4vhdlKtWxU/of/mmJysnt5SA2GBJWcJM5792T3iyBrkBtK2tO0wqWggMSK371w== X-Received: by 2002:a62:5f85:0:b029:204:99fa:3371 with SMTP id t127-20020a625f850000b029020499fa3371mr1426245pfb.1.1616026521202; Wed, 17 Mar 2021 17:15:21 -0700 (PDT) Received: from sun.local.gmail.com (219x123x138x129.ap219.ftth.ucom.ne.jp. [219.123.138.129]) by smtp.gmail.com with ESMTPSA id b3sm205952pjg.41.2021.03.17.17.15.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Mar 2021 17:15:20 -0700 (PDT) Date: Thu, 18 Mar 2021 09:15:25 +0900 Message-ID: From: Hajime Tazaki To: johannes@sipsolutions.net Cc: tavi.purdila@gmail.com, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, linux-kernel-library@freelists.org, linux-arch@vger.kernel.org, retrage01@gmail.com Subject: Re: [RFC v8 19/20] um: lkl: add block device support of UML In-Reply-To: <3d3e446409d00dfbe62320832799d0a3b34b2b9c.camel@sipsolutions.net> References: <2b649bc5165c7ff4547abd72f7e03e7491980138.camel@sipsolutions.net> <56af0e44c846f4b079256ec997c56119964be402.camel@sipsolutions.net> <3d3e446409d00dfbe62320832799d0a3b34b2b9c.camel@sipsolutions.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-arch@vger.kernel.org On Wed, 17 Mar 2021 23:28:10 +0900, Johannes Berg wrote: > > On Wed, 2021-03-17 at 16:19 +0200, Octavian Purdila wrote: > > > I can understand that your sample code wants btrfs just to show what it > > > can do, but IMHO it doesn't make sense to *always* enable it. > > Btw, what I said there also didn't distinguish between "always enable > it" and "always force it enabled". > > Right now this patch did the latter, but the former might sort of make > sense, but would take the form of a defconfig rather than a Kconfig code > change. Thanks, I understand the situation. I agree that using defconfig should be good in this case. Will fix this. > > I agree. I think these can stay in defconfigs but here is where a > > library introduces complications which I don't know how is best to > > handle. Should we have the defconfig in arch/um or should we have it > > in tools/testing/selftests/um? Or perhaps both places, one being a > > generic config that would be used by most applications and one > > customized? > > Yeah, that's a question - and in that sense LKL will never be a general- > purpose "library" since then you'd have to basically build it with > "allyesconfig" instead of other things. > > Maybe just put a note there with the tools, and maybe a defconfig, and > then have some kind of detection at example/tool build or even runtime > that the necessary options are selected? preparing multiple defconfigs (e.g., tiny, normal, allyes) would be one option for build-time selection. Other possibilities (rather radical) could be to prepare multiple sub-libraries (liblinux-core.so liblinux-fs-ext4.so, liblinux-net.so, etc) so that users can pick only necessary codes when it's build (or open during runtime). This needs to handle dependencies as kernel modules do, thus it's more complicated once we have this ? -- Hajime From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x432.google.com ([2607:f8b0:4864:20::432]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lMgJw-0049SS-SI for linux-um@lists.infradead.org; Thu, 18 Mar 2021 00:15:26 +0000 Received: by mail-pf1-x432.google.com with SMTP id l3so2253969pfc.7 for ; Wed, 17 Mar 2021 17:15:22 -0700 (PDT) Date: Thu, 18 Mar 2021 09:15:25 +0900 Message-ID: From: Hajime Tazaki Subject: Re: [RFC v8 19/20] um: lkl: add block device support of UML In-Reply-To: <3d3e446409d00dfbe62320832799d0a3b34b2b9c.camel@sipsolutions.net> References: <2b649bc5165c7ff4547abd72f7e03e7491980138.camel@sipsolutions.net> <56af0e44c846f4b079256ec997c56119964be402.camel@sipsolutions.net> <3d3e446409d00dfbe62320832799d0a3b34b2b9c.camel@sipsolutions.net> MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-um" Errors-To: linux-um-bounces+geert=linux-m68k.org@lists.infradead.org To: johannes@sipsolutions.net Cc: tavi.purdila@gmail.com, linux-um@lists.infradead.org, jdike@addtoit.com, richard@nod.at, anton.ivanov@cambridgegreys.com, linux-kernel-library@freelists.org, linux-arch@vger.kernel.org, retrage01@gmail.com On Wed, 17 Mar 2021 23:28:10 +0900, Johannes Berg wrote: > > On Wed, 2021-03-17 at 16:19 +0200, Octavian Purdila wrote: > > > I can understand that your sample code wants btrfs just to show what it > > > can do, but IMHO it doesn't make sense to *always* enable it. > > Btw, what I said there also didn't distinguish between "always enable > it" and "always force it enabled". > > Right now this patch did the latter, but the former might sort of make > sense, but would take the form of a defconfig rather than a Kconfig code > change. Thanks, I understand the situation. I agree that using defconfig should be good in this case. Will fix this. > > I agree. I think these can stay in defconfigs but here is where a > > library introduces complications which I don't know how is best to > > handle. Should we have the defconfig in arch/um or should we have it > > in tools/testing/selftests/um? Or perhaps both places, one being a > > generic config that would be used by most applications and one > > customized? > > Yeah, that's a question - and in that sense LKL will never be a general- > purpose "library" since then you'd have to basically build it with > "allyesconfig" instead of other things. > > Maybe just put a note there with the tools, and maybe a defconfig, and > then have some kind of detection at example/tool build or even runtime > that the necessary options are selected? preparing multiple defconfigs (e.g., tiny, normal, allyes) would be one option for build-time selection. Other possibilities (rather radical) could be to prepare multiple sub-libraries (liblinux-core.so liblinux-fs-ext4.so, liblinux-net.so, etc) so that users can pick only necessary codes when it's build (or open during runtime). This needs to handle dependencies as kernel modules do, thus it's more complicated once we have this ? -- Hajime _______________________________________________ linux-um mailing list linux-um@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-um