Update the sentence in livepatch.rst to: "Functions are there for a reason. Take some input parameters, acquire or release locks, read, process, and write some data in a defined way."
Signed-off-by: Attreyee Mukherjee <[email protected]>
---
Documentation/livepatch/livepatch.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/livepatch/livepatch.rst b/Documentation/livepatch/livepatch.rst
index 68e3651e8af9..acb90164929e 100644
--- a/Documentation/livepatch/livepatch.rst
+++ b/Documentation/livepatch/livepatch.rst
@@ -50,7 +50,7 @@ some limitations, see below.
3. Consistency model
====================
-Functions are there for a reason. They take some input parameters, get or
+Functions are there for a reason. They take some input parameters, acquire or
release locks, read, process, and even write some data in a defined way,
have return values. In other words, each function has a defined semantic.
--
2.34.1
attreyee-muk <[email protected]> writes:
> Update the sentence in livepatch.rst to: "Functions are there for a reason. Take some input parameters, acquire or release locks, read, process, and write some data in a defined way."
>
> Signed-off-by: Attreyee Mukherjee <[email protected]>
> ---
> Documentation/livepatch/livepatch.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
So this is a classic example of saying what you have done, but not why.
What makes this a change that we want?
Also, please wrap your changelogs to a reasonable line length.
Thanks,
jon
On Sat, Dec 23, 2023 at 03:08:54PM -0700, Jonathan Corbet wrote:
> attreyee-muk <[email protected]> writes:
>
> > Update the sentence in livepatch.rst to: "Functions are there for a reason. Take some input parameters, acquire or release locks, read, process, and write some data in a defined way."
> >
> > Signed-off-by: Attreyee Mukherjee <[email protected]>
> > ---
> > Documentation/livepatch/livepatch.rst | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> So this is a classic example of saying what you have done, but not why.
> What makes this a change that we want?
I think what he intended was "The word 'get' is not the correct antonym to
'release' in the context of locking. Replace it with 'acquire'".
Thanks.
--
An old man doll... just what I always wanted! - Clara
Hello maintainers,
I wanted to ask if this patch of mine is accepted as of now.
Thank you
Attreyee Mukherjee
On Tue, 26 Dec 2023 at 10:22, Bagas Sanjaya <[email protected]> wrote:
>
> On Sat, Dec 23, 2023 at 03:08:54PM -0700, Jonathan Corbet wrote:
> > attreyee-muk <[email protected]> writes:
> >
> > > Update the sentence in livepatch.rst to: "Functions are there for a reason. Take some input parameters, acquire or release locks, read, process, and write some data in a defined way."
> > >
> > > Signed-off-by: Attreyee Mukherjee <[email protected]>
> > > ---
> > > Documentation/livepatch/livepatch.rst | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > So this is a classic example of saying what you have done, but not why.
> > What makes this a change that we want?
>
> I think what he intended was "The word 'get' is not the correct antonym to
> 'release' in the context of locking. Replace it with 'acquire'".
>
> Thanks.
>
> --
> An old man doll... just what I always wanted! - Clara
Attreyee M <[email protected]> writes:
> Hello maintainers,
>
> I wanted to ask if this patch of mine is accepted as of now.
You never responded to the question that is still quoted in your
(unfortunately top-posted) email:
> So this is a classic example of saying what you have done, but not why.
> What makes this a change that we want?
So no, not accepted. Even with a proper changelog, though, I'm not sure
I see the value in that particular change.
jon
As Bagas Sanjaya wrote in the email before about the change, I thought
the reason was explained.
I am sorry that I didn't respond to it thinking that.
Thank you
Attreyee Mukherjee
On Wed, 10 Jan 2024 at 23:45, Jonathan Corbet <[email protected]> wrote:
>
> Attreyee M <[email protected]> writes:
>
> > Hello maintainers,
> >
> > I wanted to ask if this patch of mine is accepted as of now.
>
> You never responded to the question that is still quoted in your
> (unfortunately top-posted) email:
>
> > So this is a classic example of saying what you have done, but not why.
> > What makes this a change that we want?
>
> So no, not accepted. Even with a proper changelog, though, I'm not sure
> I see the value in that particular change.
>
> jon
On Wed, 2024-01-10 at 11:15 -0700, Jonathan Corbet wrote:
> Attreyee M <[email protected]> writes:
>
> > Hello maintainers,
> >
> > I wanted to ask if this patch of mine is accepted as of now.
>
> You never responded to the question that is still quoted in your
> (unfortunately top-posted) email:
>
> > So this is a classic example of saying what you have done, but not
> > why.
> > What makes this a change that we want?
>
> So no, not accepted. Even with a proper changelog, though, I'm not
> sure
> I see the value in that particular change.
From time to time I see people complaining about the lack of new people
coming to kernel development, and that Documentation would be a good
start for some of them to learn how to send patches by email (which by
itself is difficult...).
As Documentation patches aren't backported, why not accept this patch?
Jon, I understand your reasoning, but I agree with Attreyee here. The
term "acquire" fits better when in conjunction with "released" than
"get".
Can you show an example of a good commit message to Attreyee so he can
adjust and resend? I'm sure the next time he'll consider remember the
suggestion given and the next patch will have a better commit message.
Thanks,
Marcos
>
> jon
>
On Wed 2024-01-10 15:51:40, Marcos Paulo de Souza wrote:
> On Wed, 2024-01-10 at 11:15 -0700, Jonathan Corbet wrote:
> > Attreyee M <[email protected]> writes:
> >
> > > Hello maintainers,
> > >
> > > I wanted to ask if this patch of mine is accepted as of now.
> >
> > You never responded to the question that is still quoted in your
> > (unfortunately top-posted) email:
> >
> > > So this is a classic example of saying what you have done, but not
> > > why.
> > > What makes this a change that we want?
> >
> > So no, not accepted.? Even with a proper changelog, though, I'm not
> > sure
> > I see the value in that particular change.
>
> >From time to time I see people complaining about the lack of new people
> coming to kernel development,
IMHO, it is much worse on the maintainers' side. There is a lack
of maintainers. And I believe that most of them have hard times
to manage the load. They should provide hints. But we could
not expect that they would do the work.
> and that Documentation would be a good
> start for some of them to learn how to send patches by email (which by
> itself is difficult...).
Attreyee, please read Documentation/process/submitting-patches.rst
before you send another version.
Also please run scripts/checkpatch.pl before you send the patches.
> As Documentation patches aren't backported, why not accept this patch?
>
> Jon, I understand your reasoning, but I agree with Attreyee here. The
> term "acquire" fits better when in conjunction with "released" than
> "get".
>
> Can you show an example of a good commit message to Attreyee so he can
> adjust and resend? I'm sure the next time he'll consider remember the
> suggestion given and the next patch will have a better commit message.
I suggest that Attreyee makes another attempt himself.
John explained what was the problem. Attreyee could get inspiration from
the git history. Anyway, the commit message simply should explain why
"acquire" is better than "get".
Best Regards,
Petr