Message ID | 20230209192009.7885-4-sj@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp527430wrn; Thu, 9 Feb 2023 11:25:10 -0800 (PST) X-Google-Smtp-Source: AK7set9RZf4T1EO6EJAb3rtplQiuoDwWZ263MX0O195mwbYZAKkCMqPiGf7ZhYEbXqjsIQyn4mJk X-Received: by 2002:a17:906:db0b:b0:8ae:80d5:7385 with SMTP id xj11-20020a170906db0b00b008ae80d57385mr9661093ejb.10.1675970710152; Thu, 09 Feb 2023 11:25:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675970710; cv=none; d=google.com; s=arc-20160816; b=m8UwvmzkV8PMErz7X3bht+LVqWK/amvs/iUo5zbOceZJ36okdwoFgEvAEK7nVNUayW U3y8HnKRhgR1hX/X9JxUmHaGYHitXB7YESjttuHKkl4m6t+fJo+oCsftGKhJB387r4Oy tlKLPnM1IR8+6/K3j6t3jqcVtwZ0QEOwlDR9ACp1HyhHdg+Z9gCXuzWwI/wK9v+HLesU BadwXAQNCWjn5lO4JNgCPeUXigTnKO2HDtCE+lJBplGfkj/9HW2eWbsxtniuc5DsjxeD fGvi6sKYYixMOgf3bcX4zwBzQRoV4ABQiCE8W7kZ2NRf1zT/wN2Jx37oAFDx1/I8KQ04 +Hcg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=v/ZbcDDyGp1GCgR/7hYyVbx4tuFen8J1znyyD4wVL8g=; b=Nm1GfAe9KH4zOxEzX37bmQ7z65lO3yBQJwHtYVM71x+QBF5Sm6CgbRMOALOFWTlRom bhElngPhwgB82FEad+R16dol9vfqVl1NbZTE7dxZsIVirFKmhzZWipO+G6dc1Rgt/V/n xv7IA8Gk9xtRmpJ19psNlFVAEiWdJ37PRqRi+al+w8eiIBH0BIi2TsfIlKvywJYP047H O/2I/qC1rh7YnMul/Bbwrz08iYqYQqfg5px46PXoGSg/9SHmbfKYFEl1Qr082j1GbnwJ TU7uJ4lyF26PeMr+ZTwWXFo1mEvHpqtwHMM3racAUNCxp3N7ghinRBQrGvwRVw4FqFvp Lqbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YNwNncax; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id fx33-20020a1709069ea100b008778ad3ca00si3495240ejc.234.2023.02.09.11.24.46; Thu, 09 Feb 2023 11:25:10 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=YNwNncax; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230084AbjBITUV (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 9 Feb 2023 14:20:21 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229545AbjBITUS (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Feb 2023 14:20:18 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CEF625356F for <linux-kernel@vger.kernel.org>; Thu, 9 Feb 2023 11:20:17 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6BCC361BB5 for <linux-kernel@vger.kernel.org>; Thu, 9 Feb 2023 19:20:17 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7C11FC433A1; Thu, 9 Feb 2023 19:20:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675970416; bh=YKnuEvRI6qfPAJO2dUUkfnH+bQPuZPD2yzEq+Lx0+z4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=YNwNncaxqJtNLK1jiU8L7oyV++uilfm1Jne4U3kLLB385NSqtdiYkJ9f+YuB4rOdK r8irMblAq+as8w9prFXzUhRqT+sN+Q8MUOX4T2Cct1ET47M1Wj8YGIxL9yvdIt+GQX tJrmah8kxg9jC8ep0z3I06JWRIl1Y652uHmKIWsjWEVZ6cbkf3A7U5L3N//AQDz4Xf FbHuAgyGYxo05IvYJnqmOh72HjluzjCiL/YsfqTdGsa9yqVhZU0WXMzbM5FtgWLRj/ 7SfnQPPzftZC0eIW4SR3pZgk8QhRJV6q5mTmj6nX2NU2shlUhkKAdA36QETg86+6oi wWowqMT+cl1zw== From: SeongJae Park <sj@kernel.org> To: Andrew Morton <akpm@linux-foundation.org> Cc: SeongJae Park <sj@kernel.org>, damon@lists.linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [PATCH 3/3] mm/damon/dbgfs: print DAMON debugfs interface deprecation message Date: Thu, 9 Feb 2023 19:20:09 +0000 Message-Id: <20230209192009.7885-4-sj@kernel.org> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20230209192009.7885-1-sj@kernel.org> References: <20230209192009.7885-1-sj@kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757382663326578860?= X-GMAIL-MSGID: =?utf-8?q?1757382663326578860?= |
Series |
[1/3] Docs/admin-guide/mm/damon/usage: add DAMON debugfs interface deprecation notice
|
|
Commit Message
SeongJae Park
Feb. 9, 2023, 7:20 p.m. UTC
DAMON debugfs interface has announced to be deprecated after >v5.15 LTS
kernel is released. And, v6.1.y has announced to be an LTS[1].
Though the announcement was there for a while, some people might not
noticed that so far. Also, some users could depend on it and have
problems at movng to the alternative (DAMON sysfs interface).
For such cases, warn DAMON debugfs interface deprecation with contacts
to ask helps when any DAMON debugfs interface file is opened.
[1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c
Signed-off-by: SeongJae Park <sj@kernel.org>
---
mm/damon/dbgfs.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
Comments
Hi, On 2/9/23 11:20, SeongJae Park wrote: > DAMON debugfs interface has announced to be deprecated after >v5.15 LTS > kernel is released. And, v6.1.y has announced to be an LTS[1]. > > Though the announcement was there for a while, some people might not > noticed that so far. Also, some users could depend on it and have > problems at movng to the alternative (DAMON sysfs interface). > > For such cases, warn DAMON debugfs interface deprecation with contacts > to ask helps when any DAMON debugfs interface file is opened. > > [1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c > > Signed-off-by: SeongJae Park <sj@kernel.org> > --- > mm/damon/dbgfs.c | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c > index b3f454a5c682..e551a20b35e3 100644 > --- a/mm/damon/dbgfs.c > +++ b/mm/damon/dbgfs.c > @@ -20,6 +20,11 @@ static int dbgfs_nr_ctxs; > static struct dentry **dbgfs_dirs; > static DEFINE_MUTEX(damon_dbgfs_lock); > > +static void damon_dbgfs_warn_deprecation(void) > +{ > + pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > +} Line length of 234 is a bit over the limit. I think it would be OK to split it at the end of the first sentence, like: pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); pr_warn_once("If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); or would that [2 pr_warn_once() calls] not work for some reason? Or even: pr_warn_once( "DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); pr_warn_once( "If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); although some people might gag at that one.
Hi Randy, On Thu, 9 Feb 2023 19:26:43 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > Hi, > > On 2/9/23 11:20, SeongJae Park wrote: > > DAMON debugfs interface has announced to be deprecated after >v5.15 LTS > > kernel is released. And, v6.1.y has announced to be an LTS[1]. > > > > Though the announcement was there for a while, some people might not > > noticed that so far. Also, some users could depend on it and have > > problems at movng to the alternative (DAMON sysfs interface). > > > > For such cases, warn DAMON debugfs interface deprecation with contacts > > to ask helps when any DAMON debugfs interface file is opened. > > > > [1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c > > > > Signed-off-by: SeongJae Park <sj@kernel.org> > > --- > > mm/damon/dbgfs.c | 16 ++++++++++++++++ > > 1 file changed, 16 insertions(+) > > > > diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c > > index b3f454a5c682..e551a20b35e3 100644 > > --- a/mm/damon/dbgfs.c > > +++ b/mm/damon/dbgfs.c > > @@ -20,6 +20,11 @@ static int dbgfs_nr_ctxs; > > static struct dentry **dbgfs_dirs; > > static DEFINE_MUTEX(damon_dbgfs_lock); > > > > +static void damon_dbgfs_warn_deprecation(void) > > +{ > > + pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > > +} > > Line length of 234 is a bit over the limit. > I think it would be OK to split it at the end of the first sentence, like: > > pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); > pr_warn_once("If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > > or would that [2 pr_warn_once() calls] not work for some reason? > > Or even: > > pr_warn_once( > "DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); > pr_warn_once( > "If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > > although some people might gag at that one. Thank you for your opinion. I considered that, but I was worrying if some other messages come between those two separated messages. What do you think about breaking the string like below? I first tried to do so like memcg hierarchy[1], but ended up to this version because of checkpatch.pl outputs[2]. However, if others doesn't care, I think this is ok. pr_warn_once("DAMON debugfs interface is deprecated, " "so users should move DAMON_SYSFS. If you depend on this " "and cannot move, please report your usecase to " "damon@lists.linux.dev and linux-mm@kvack.org.\n"); If breaking user-visible string is not ok, maybe we could make it as short as your above example. pr_warn_once("DAMON_DBGFS is deprecated; please contact to damon@lists.linux.dev and linux-mm@kvack.org if you depend on it.\n"); May I ask your opinion? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/memcontrol.c?h=v6.1#n3643 [2] https://docs.kernel.org/process/coding-style.html#breaking-long-lines-and-strings Thanks, SJ > > > -- > ~Randy
Hi, On 2/9/23 20:24, SeongJae Park wrote: > Hi Randy, > > On Thu, 9 Feb 2023 19:26:43 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > >> Hi, >> >> On 2/9/23 11:20, SeongJae Park wrote: >>> DAMON debugfs interface has announced to be deprecated after >v5.15 LTS >>> kernel is released. And, v6.1.y has announced to be an LTS[1]. >>> >>> Though the announcement was there for a while, some people might not >>> noticed that so far. Also, some users could depend on it and have >>> problems at movng to the alternative (DAMON sysfs interface). >>> >>> For such cases, warn DAMON debugfs interface deprecation with contacts >>> to ask helps when any DAMON debugfs interface file is opened. >>> >>> [1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c >>> >>> Signed-off-by: SeongJae Park <sj@kernel.org> >>> --- >>> mm/damon/dbgfs.c | 16 ++++++++++++++++ >>> 1 file changed, 16 insertions(+) >>> >>> diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c >>> index b3f454a5c682..e551a20b35e3 100644 >>> --- a/mm/damon/dbgfs.c >>> +++ b/mm/damon/dbgfs.c >>> @@ -20,6 +20,11 @@ static int dbgfs_nr_ctxs; >>> static struct dentry **dbgfs_dirs; >>> static DEFINE_MUTEX(damon_dbgfs_lock); >>> >>> +static void damon_dbgfs_warn_deprecation(void) >>> +{ >>> + pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); >>> +} >> >> Line length of 234 is a bit over the limit. >> I think it would be OK to split it at the end of the first sentence, like: >> >> pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); >> pr_warn_once("If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); >> >> or would that [2 pr_warn_once() calls] not work for some reason? >> >> Or even: >> >> pr_warn_once( >> "DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); >> pr_warn_once( >> "If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); >> >> although some people might gag at that one. > > Thank you for your opinion. > > I considered that, but I was worrying if some other messages come between those > two separated messages. I see. > > What do you think about breaking the string like below? I first tried to do so > like memcg hierarchy[1], but ended up to this version because of checkpatch.pl > outputs[2]. However, if others doesn't care, I think this is ok. It's OK to ignore checkpatch sometimes. :) > > pr_warn_once("DAMON debugfs interface is deprecated, " > "so users should move DAMON_SYSFS. If you depend on this " > "and cannot move, please report your usecase to " > "damon@lists.linux.dev and linux-mm@kvack.org.\n"); > > If breaking user-visible string is not ok, maybe we could make it as short as > your above example. > > pr_warn_once("DAMON_DBGFS is deprecated; please contact to damon@lists.linux.dev and linux-mm@kvack.org if you depend on it.\n"); > > May I ask your opinion? I'm OK with either one of these, but I prefer your first example over the second one. > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/memcontrol.c?h=v6.1#n3643 > [2] https://docs.kernel.org/process/coding-style.html#breaking-long-lines-and-strings Thanks.
On Thu, 9 Feb 2023 20:32:21 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > Hi, > > On 2/9/23 20:24, SeongJae Park wrote: > > Hi Randy, > > > > On Thu, 9 Feb 2023 19:26:43 -0800 Randy Dunlap <rdunlap@infradead.org> wrote: > > > >> Hi, > >> > >> On 2/9/23 11:20, SeongJae Park wrote: > >>> DAMON debugfs interface has announced to be deprecated after >v5.15 LTS > >>> kernel is released. And, v6.1.y has announced to be an LTS[1]. > >>> > >>> Though the announcement was there for a while, some people might not > >>> noticed that so far. Also, some users could depend on it and have > >>> problems at movng to the alternative (DAMON sysfs interface). > >>> > >>> For such cases, warn DAMON debugfs interface deprecation with contacts > >>> to ask helps when any DAMON debugfs interface file is opened. > >>> > >>> [1] https://git.kernel.org/pub/scm/docs/kernel/website.git/commit/?id=332e9121320bc7461b2d3a79665caf153e51732c > >>> > >>> Signed-off-by: SeongJae Park <sj@kernel.org> > >>> --- > >>> mm/damon/dbgfs.c | 16 ++++++++++++++++ > >>> 1 file changed, 16 insertions(+) > >>> > >>> diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c > >>> index b3f454a5c682..e551a20b35e3 100644 > >>> --- a/mm/damon/dbgfs.c > >>> +++ b/mm/damon/dbgfs.c > >>> @@ -20,6 +20,11 @@ static int dbgfs_nr_ctxs; > >>> static struct dentry **dbgfs_dirs; > >>> static DEFINE_MUTEX(damon_dbgfs_lock); > >>> > >>> +static void damon_dbgfs_warn_deprecation(void) > >>> +{ > >>> + pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > >>> +} > >> > >> Line length of 234 is a bit over the limit. > >> I think it would be OK to split it at the end of the first sentence, like: > >> > >> pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); > >> pr_warn_once("If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > >> > >> or would that [2 pr_warn_once() calls] not work for some reason? > >> > >> Or even: > >> > >> pr_warn_once( > >> "DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS).\n"); > >> pr_warn_once( > >> "If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); > >> > >> although some people might gag at that one. > > > > Thank you for your opinion. > > > > I considered that, but I was worrying if some other messages come between those > > two separated messages. > > I see. > > > > > What do you think about breaking the string like below? I first tried to do so > > like memcg hierarchy[1], but ended up to this version because of checkpatch.pl > > outputs[2]. However, if others doesn't care, I think this is ok. > > It's OK to ignore checkpatch sometimes. :) > > > > > pr_warn_once("DAMON debugfs interface is deprecated, " > > "so users should move DAMON_SYSFS. If you depend on this " > > "and cannot move, please report your usecase to " > > "damon@lists.linux.dev and linux-mm@kvack.org.\n"); > > > > If breaking user-visible string is not ok, maybe we could make it as short as > > your above example. > > > > pr_warn_once("DAMON_DBGFS is deprecated; please contact to damon@lists.linux.dev and linux-mm@kvack.org if you depend on it.\n"); > > > > May I ask your opinion? > > I'm OK with either one of these, but I prefer your first example over the second one. Thank you for quick reply. I will send v2 with the first one. Thanks, SJ > > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/mm/memcontrol.c?h=v6.1#n3643 > > [2] https://docs.kernel.org/process/coding-style.html#breaking-long-lines-and-strings > > Thanks. > -- > ~Randy >
diff --git a/mm/damon/dbgfs.c b/mm/damon/dbgfs.c index b3f454a5c682..e551a20b35e3 100644 --- a/mm/damon/dbgfs.c +++ b/mm/damon/dbgfs.c @@ -20,6 +20,11 @@ static int dbgfs_nr_ctxs; static struct dentry **dbgfs_dirs; static DEFINE_MUTEX(damon_dbgfs_lock); +static void damon_dbgfs_warn_deprecation(void) +{ + pr_warn_once("DAMON debugfs interface is deprecated, so users should move to the sysfs interface (DAMON_SYSFS). If you depend on this and cannot move, please report your usecase to damon@lists.linux.dev and linux-mm@kvack.org.\n"); +} + /* * Returns non-empty string on success, negative error code otherwise. */ @@ -711,6 +716,8 @@ static ssize_t dbgfs_kdamond_pid_read(struct file *file, static int damon_dbgfs_open(struct inode *inode, struct file *file) { + damon_dbgfs_warn_deprecation(); + file->private_data = inode->i_private; return nonseekable_open(inode, file); @@ -1039,15 +1046,24 @@ static ssize_t dbgfs_monitor_on_write(struct file *file, return ret; } +static int damon_dbgfs_static_file_open(struct inode *inode, struct file *file) +{ + damon_dbgfs_warn_deprecation(); + return nonseekable_open(inode, file); +} + static const struct file_operations mk_contexts_fops = { + .open = damon_dbgfs_static_file_open, .write = dbgfs_mk_context_write, }; static const struct file_operations rm_contexts_fops = { + .open = damon_dbgfs_static_file_open, .write = dbgfs_rm_context_write, }; static const struct file_operations monitor_on_fops = { + .open = damon_dbgfs_static_file_open, .read = dbgfs_monitor_on_read, .write = dbgfs_monitor_on_write, };