[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <4DE98E35-2D1F-4A4E-8689-35FD246606EF@gmail.com>
Date: Tue, 4 Jun 2024 16:14:51 +0800
From: zhang warden <zhangwarden@...il.com>
To: Joe Lawrence <joe.lawrence@...hat.com>
Cc: Miroslav Benes <mbenes@...e.cz>,
Josh Poimboeuf <jpoimboe@...nel.org>,
Jiri Kosina <jikos@...nel.org>,
Petr Mladek <pmladek@...e.com>,
live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: introduce klp_func called interface
> On Jun 1, 2024, at 03:16, Joe Lawrence <joe.lawrence@...hat.com> wrote:
>
> Adding these attributes to livepatch sysfs would be expedient and
> probably easier for us to use, but imposes a recurring burden on us to
> maintain and test (where is the documentation and kselftest for this new
> interface?). Or, we could let the other tools handle all of that for
> us.
How this attribute imposes a recurring burden to maintain and test?
> Perhaps if someone already has an off-the-shelf script that is using
> ftrace to monitor livepatched code, it could be donated to
> Documentation/livepatch/? I can ask our QE folks if they have something
> like this.
My intention to introduce this attitude to sysfs is that user who what to see if this function is called can just need to show this function attribute in the livepatch sysfs interface.
User who have no experience of using ftrace will have problems to get the calling state of the patched function. After all, ftrace is a professional kernel tracing tools.
Adding this attribute will be more easier for us to show if this patched function is called. Actually, I have never try to use ftrace to trace a patched function. Is it OK of using ftrace for a livepatched function?
Regards,
Wardenjohn
Powered by blists - more mailing lists