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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 F34E3C433E2 for ; Wed, 9 Sep 2020 07:17:51 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 96B5021D7B for ; Wed, 9 Sep 2020 07:17:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="AvT8dnL5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96B5021D7B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 2506B13CA1C27; Wed, 9 Sep 2020 00:17:51 -0700 (PDT) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.145.29.99; helo=mail.kernel.org; envelope-from=gregkh@linuxfoundation.org; receiver= Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 5FC871398438A for ; Wed, 9 Sep 2020 00:17:49 -0700 (PDT) Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6E9DD2078E; Wed, 9 Sep 2020 07:17:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599635869; bh=HM+rzaB8jIQfL0goRXEpQy9E5vp1Tz0Xya2N8+sURa8=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=AvT8dnL52SNWoRsYGkEMucCNddyCJQuXVVABi6KWtNROiarVGoZIIksdgH++GXUk/ mfX6EAUKLeKSOnJ2qoBI3uXM/U1aG8XaU0+hDOa7Lt1OcLDpieALm74V9UfqnUSe0L mSA2BCCpW8HVUTBtZhu/0DJnEr8IcSkO0W2pwNvs= Date: Wed, 9 Sep 2020 09:17:59 +0200 From: Greg Kroah-Hartman To: David Hildenbrand Subject: Re: [PATCH v2 3/7] mm/memory_hotplug: prepare passing flags to add_memory() and friends Message-ID: <20200909071759.GD435421@kroah.com> References: <20200908201012.44168-1-david@redhat.com> <20200908201012.44168-4-david@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200908201012.44168-4-david@redhat.com> Message-ID-Hash: 6WVZNIIAGUBGSCJUTAFT6HW2EQQZF5T3 X-Message-ID-Hash: 6WVZNIIAGUBGSCJUTAFT6HW2EQQZF5T3 X-MailFrom: gregkh@linuxfoundation.org X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-mm@kvack.org, linux-hyperv@vger.kernel.org, xen-devel@lists.xenproject.org, linux-acpi@vger.kernel.org, linux-nvdimm@lists.01.org, linux-s390@vger.kernel.org, Andrew Morton , Wei Liu , Michal Hocko , Jason Gunthorpe , Pankaj Gupta , Baoquan He , Michael Ellerman , Benjamin Herrenschmidt , Paul Mackerras , "Rafael J. Wysocki" , Len Brown , "K. Y. Srinivasan" , Haiyang Zhang , Stephen Hemminger , Heiko Carstens , Vasily Gorbik , Christian Borntraeger , "Michael S. Tsirkin" , Jason Wang , Boris Ostrovsky , Juergen Gross , Stefano Stabellini , Pingfan Liu , Nathan Lynch , Libor Pechacek , Anton Blanchard , Leonardo Bras , linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit On Tue, Sep 08, 2020 at 10:10:08PM +0200, David Hildenbrand wrote: > We soon want to pass flags, e.g., to mark added System RAM resources. > mergeable. Prepare for that. What are these random "flags", and how do we know what should be passed to them? Why not make this an enumerated type so that we know it all works properly, like the GPF_* flags are? Passing around a random unsigned long feels very odd/broken... thanks, greg k-h _______________________________________________ Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org To unsubscribe send an email to linux-nvdimm-leave@lists.01.org