{"thread":{"id":"57882","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","startedAt":"2022-05-14T14:37:50Z","lastAt":"2022-05-18T17:21:46Z","messageCount":6,"participants":["Alejandro Colomar","Martin Ågren","Theodore Dubois","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"455290","messageId":"0fc70bd3-5883-47e4-1814-6ed6c756a400@gmail.com","threadId":"57882","inReplyTo":"20220510220821.1481801-1-tbodt@google.com","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","fromName":"Alejandro Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2022-05-14T14:37:41Z","receivedAt":"2022-05-14T14:37:50Z","isPatch":true,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Theodore,\n\nOn 5/11/22 00:08, Theodore Dubois wrote:\n> The translation is needed to avoid returning a negative number from a\n> successful syscall, and this requirement doesn't apply to setpriority.\n> See the implementation of getpriority in kernel/sys.c.\n> \n> Signed-off-by: Theodore Dubois \n\nPatch applied.\n\nBTW, I had to manually edit the patch.\nIt's the second time I see this (I can't find the other one), your patch \ndidn't apply for the following reason: the a/ and b/ prefixes in the \nfile paths are missing. Did you use git-format-patch(1) to produce the \npatch? Can you reproduce this?\n\nI CCd the git mailing list in case they know what's going on.\n\nThanks,\n\nAlex\n\n> ---\n> man2/getpriority.2 | 17 ++++-------------\n> 1 file changed, 4 insertions(+), 13 deletions(-)\n> \n> diff --git man2/getpriority.2 man2/getpriority.2\n\nShould have been:\ndiff --git a/man2/getpriority.2 b/man2/getpriority.2\n\n> index 3e1be3e6c..24c1b7f11 100644\n> --- man2/getpriority.2\n> +++ man2/getpriority.2\n\nShould have been:\n\n--- a/man2/getpriority.2\n+++ b/man2/getpriority.2\n\n\n> @@ -206,20 +206,11 @@ All BSD-like systems (SunOS 4.1.3, Ultrix 4.2,\n> manner as Linux 2.6.12 and later.\n> .\\\"\n> .SS C library/kernel differences\n> -Within the kernel, nice values are actually represented\n> -using the range 40..1\n> -(since negative numbers are error codes) and these are the values\n> -employed by the\n> -.BR setpriority ()\n> -and\n> -.BR getpriority ()\n> -system calls.\n> -The glibc wrapper functions for these system calls handle the\n> -translations between the user-land and kernel representations\n> -of the nice value according to the formula\n> +The getpriority system call returns nice values translated to the range 40..1,\n> +since a negative return value would be interpreted as an error.\n> +The glibc wrapper function for getpriority translates the value back according to the formula\n> .IR \"unice\\ =\\ 20\\ \\-\\ knice\" .\n> -(Thus, the kernel's 40..1 range corresponds to the\n> -range \\-20..19 as seen by user space.)\n> +(Thus, the 40..1 range returned by the kernel corresponds to the range \\-20..19 as seen by user space.)\n> .SH BUGS\n> According to POSIX, the nice value is a per-process setting.\n> However, under the current Linux/NPTL implementation of POSIX threads,\n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"455291","messageId":"76ff060f-a3f2-2e60-5b1a-4a59cf3f3d8c@gmail.com","threadId":"57882","inReplyTo":"0fc70bd3-5883-47e4-1814-6ed6c756a400@gmail.com","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","fromName":"Alejandro Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2022-05-14T15:00:14Z","receivedAt":"2022-05-14T15:00:25Z","isPatch":true,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"[CC += nick]\n\nOn 5/14/22 16:37, Alejandro Colomar wrote:\n> Hi Theodore,\n> \n> On 5/11/22 00:08, Theodore Dubois wrote:\n>> The translation is needed to avoid returning a negative number from a\n>> successful syscall, and this requirement doesn't apply to setpriority.\n>> See the implementation of getpriority in kernel/sys.c.\n>>\n>> Signed-off-by: Theodore Dubois \n> \n> Patch applied.\n> \n> BTW, I had to manually edit the patch.\n> It's the second time I see this (I can't find the other one), your patch \n\nThe other one:\n\n\n\nnick, I finally found it again!\n\n> didn't apply for the following reason: the a/ and b/ prefixes in the \n> file paths are missing.  Did you use git-format-patch(1) to produce the \n> patch?  Can you reproduce this?\n> \n> I CCd the git mailing list in case they know what's going on.\n> \n> Thanks,\n> \n> Alex\n> \n>> ---\n>>   man2/getpriority.2 | 17 ++++-------------\n>>   1 file changed, 4 insertions(+), 13 deletions(-)\n>>\n>> diff --git man2/getpriority.2 man2/getpriority.2\n> \n> Should have been:\n> diff --git a/man2/getpriority.2 b/man2/getpriority.2\n> \n>> index 3e1be3e6c..24c1b7f11 100644\n>> --- man2/getpriority.2\n>> +++ man2/getpriority.2\n> \n> Should have been:\n> \n> --- a/man2/getpriority.2\n> +++ b/man2/getpriority.2\n> \n> \n>> @@ -206,20 +206,11 @@ All BSD-like systems (SunOS 4.1.3, Ultrix 4.2,\n>>   manner as Linux 2.6.12 and later.\n>>   .\\\"\n>>   .SS C library/kernel differences\n>> -Within the kernel, nice values are actually represented\n>> -using the range 40..1\n>> -(since negative numbers are error codes) and these are the values\n>> -employed by the\n>> -.BR setpriority ()\n>> -and\n>> -.BR getpriority ()\n>> -system calls.\n>> -The glibc wrapper functions for these system calls handle the\n>> -translations between the user-land and kernel representations\n>> -of the nice value according to the formula\n>> +The getpriority system call returns nice values translated to the \n>> range 40..1,\n>> +since a negative return value would be interpreted as an error.\n>> +The glibc wrapper function for getpriority translates the value back \n>> according to the formula\n>>   .IR \"unice\\ =\\ 20\\ \\-\\ knice\" .\n>> -(Thus, the kernel's 40..1 range corresponds to the\n>> -range \\-20..19 as seen by user space.)\n>> +(Thus, the 40..1 range returned by the kernel corresponds to the \n>> range \\-20..19 as seen by user space.)\n>>   .SH BUGS\n>>   According to POSIX, the nice value is a per-process setting.\n>>   However, under the current Linux/NPTL implementation of POSIX threads,\n> \n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"455293","messageId":"CAN0heSper1O2ZdFq6RE=7znC0o+sFEsd8CBR3ckFtSoZu7Bzfw@mail.gmail.com","threadId":"57882","inReplyTo":"0fc70bd3-5883-47e4-1814-6ed6c756a400@gmail.com","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","fromName":"Martin Ågren","fromEmail":"martin.agren@gmail.com","sentAt":"2022-05-14T18:43:28Z","receivedAt":"2022-05-14T18:43:43Z","isPatch":true,"sender":{"key":"martin.agren@gmail.com","avatar":null},"body":"On Sat, 14 May 2022 at 17:11, Alejandro Colomar wrote:\n>\n> BTW, I had to manually edit the patch.\n> It's the second time I see this (I can't find the other one), your patch\n> didn't apply for the following reason: the a/ and b/ prefixes in the\n> file paths are missing. Did you use git-format-patch(1) to produce the\n> patch? Can you reproduce this?\n>\n> I CCd the git mailing list in case they know what's going on.\n\nSounds like `git format-patch --no-prefix` at play. Or more likely, that\nthe `diff.noprefix` config is on. I don't think it can be cancelled out\nby a `--no-no-prefix`, unfortunately. If a script is involved in running\n`git format-patch`, maybe it's not too tedious to make it do\n\n git -c diff.noprefix=no format-patch ...\n\nto cancel the config. (If that config really does want to be on, that\nis.)\n\nThat said, something like\n\n git am -p0 ...\n\nshould help on the receiving side, by way of skipping fewer path\ncomponents when applying the patch.\n\nMartin\n"},{"id":"455294","messageId":"385751ee-416e-c2d4-849a-270092a06010@gmail.com","threadId":"57882","inReplyTo":"CAN0heSper1O2ZdFq6RE=7znC0o+sFEsd8CBR3ckFtSoZu7Bzfw@mail.gmail.com","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","fromName":"Alejandro Colomar","fromEmail":"alx.manpages@gmail.com","sentAt":"2022-05-14T21:18:05Z","receivedAt":"2022-05-14T21:18:13Z","isPatch":true,"sender":{"key":"alx.manpages@gmail.com","avatar":null},"body":"Hi Martin,\n\nOn 5/14/22 20:43, Martin Ågren wrote:\n> That said, something like\n> \n> git am -p0 ...\n> \n> should help on the receiving side, by way of skipping fewer path\n> components when applying the patch.\n\nThat works for me.\nThanks!\n\nAlex\n\n-- \nAlejandro Colomar\nLinux man-pages comaintainer; https://www.kernel.org/doc/man-pages/\nhttp://www.alejandro-colomar.es/\n"},{"id":"455391","messageId":"CAN3rvwBWBPLB+Pm14S5Nb9LOV6ajhT8qMbwi5bBm1pK_8AgN5g@mail.gmail.com","threadId":"57882","inReplyTo":"CAN0heSper1O2ZdFq6RE=7znC0o+sFEsd8CBR3ckFtSoZu7Bzfw@mail.gmail.com","subject":"Re: [PATCH] getpriority: Only getpriority translation the priority values","fromName":"Theodore Dubois","fromEmail":"tbodt@google.com","sentAt":"2022-05-17T17:02:36Z","receivedAt":"2022-05-17T17:03:04Z","isPatch":true,"sender":{"key":"tbodt@google.com","avatar":"https://avatars.githubusercontent.com/u/5678977?v=4"},"body":"Yep, I have diff.noprefix on.\n\n~Theodore\n\nOn Sat, May 14, 2022 at 11:43 AM Martin Ågren wrote:\n>\n> On Sat, 14 May 2022 at 17:11, Alejandro Colomar wrote:\n> >\n> > BTW, I had to manually edit the patch.\n> > It's the second time I see this (I can't find the other one), your patch\n> > didn't apply for the following reason: the a/ and b/ prefixes in the\n> > file paths are missing. Did you use git-format-patch(1) to produce the\n> > patch? Can you reproduce this?\n> >\n> > I CCd the git mailing list in case they know what's going on.\n>\n> Sounds like `git format-patch --no-prefix` at play. Or more likely, that\n> the `diff.noprefix` config is on. I don't think it can be cancelled out\n> by a `--no-no-prefix`, unfortunately. If a script is involved in running\n> `git format-patch`, maybe it's not too tedious to make it do\n>\n> git -c diff.noprefix=no format-patch ...\n>\n> to cancel the config. (If that config really does want to be on, that\n> is.)\n>\n> That said, something like\n>\n> git am -p0 ...\n>\n> should help on the receiving side, by way of skipping fewer path\n> components when applying the patch.\n>\n> Martin\n"},{"id":"455405","messageId":"xmqqh75mwycb.fsf_-_@gitster.g","threadId":"57882","inReplyTo":"CAN3rvwBWBPLB+Pm14S5Nb9LOV6ajhT8qMbwi5bBm1pK_8AgN5g@mail.gmail.com","subject":"Perhaps we want {diff,log,format}.noprefix and friends?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2022-05-18T17:21:40Z","receivedAt":"2022-05-18T17:21:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":">> git -c diff.noprefix=no format-patch ...\n>>\n>> to cancel the config. (If that config really does want to be on, that\n>> is.)\n>>\n>> That said, something like\n>>\n>> git am -p0 ...\n>>\n>> should help on the receiving side, by way of skipping fewer path\n>> components when applying the patch.\n\nWhile it is very reasonable for end-users to make the output of\ntheir local \"git diff\" output to their taste by setting the\ndiff.noprefix and other configuration options in the diff.*\nnamespace, it is wrong to inflict such a personal preference on\nother project participants by sending such a no-prefix patch via\n\"git format-patch\", when the convention at the receiving project is\nto use \"git am -p1\" to accept them.\n\nWe would need to tweak the configuration system so that we can more\neasily introduce \"format.noprefix\" that overrides \"diff.noprefix\"\nonly when the command being run is \"git format-patch\", perhaps? \n\nAs things stand, we could teach builtin/log.c::git_format_config()\nabout \"format.noprefix\" and make \"git format-patch\" pay attention to\nthat in addition to \"diff.noprefix\" fairly easily, but such an\napproach poorly scales. When a new configuration gets introduced in\ndiff.c::git_diff_ui_config(), builtin/log.c::git_format_config()\nwould also need to be updated.\n\nI initially started writing this with \"left over bits\" mark, but it\nseems it is a bit larger in scope than that.\n\nI also noticed that some format.* configuration variables are parsed\nin git_log_config(), not git_format_config(), so \"git log\" would end\nup honoring format.pretty and format.subjectprefix, etc., which look\nwrong but probably is way too late to \"fix\".\n\n\n"}]}