* docs: automarkup.py
@ 2023-12-27 7:55 Randy Dunlap
2023-12-27 9:08 ` Vegard Nossum
2023-12-27 11:42 ` Mauro Carvalho Chehab
0 siblings, 2 replies; 7+ messages in thread
From: Randy Dunlap @ 2023-12-27 7:55 UTC (permalink / raw)
To: Linux Doc Mailing List
Cc: Jonathan Corbet, Vegard Nossum, Nícolas F. R. A. Prado,
Mauro Carvalho Chehab
Hi,
Can anyone explain this? maybe even suggest a fix for it?
This has been around for a few weeks AFAIK. I haven't see a patch for it,
but I could have missed it.
(since 17e02586ed185 in August/2023; oh, that just fixed the move
of files to the Documentation/arch/ subdir, so maybe even longer)
In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
the flags reported in this sysfs file:
kernel-doc reports:
linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
and the output file Documentation/output/admin-guide/abi-testing.html says:
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
the flags reported in this sysfs file:</p>
so the leading "Documentation/arch" is being removed from the filename
AFAICT.
I tried changing the quoted filename from single quotes to double back quotes
`` and I tried it without any quotes, all with the same results.
--
#Randy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-27 7:55 docs: automarkup.py Randy Dunlap
@ 2023-12-27 9:08 ` Vegard Nossum
2023-12-27 22:20 ` Randy Dunlap
2023-12-27 11:42 ` Mauro Carvalho Chehab
1 sibling, 1 reply; 7+ messages in thread
From: Vegard Nossum @ 2023-12-27 9:08 UTC (permalink / raw)
To: Randy Dunlap, Linux Doc Mailing List
Cc: Jonathan Corbet, Nícolas F. R. A. Prado, Mauro Carvalho Chehab
On 27/12/2023 08:55, Randy Dunlap wrote:
> Can anyone explain this? maybe even suggest a fix for it?
>
> This has been around for a few weeks AFAIK. I haven't see a patch for it,
> but I could have missed it.
>
> (since 17e02586ed185 in August/2023; oh, that just fixed the move
> of files to the Documentation/arch/ subdir, so maybe even longer)
>
>
> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
>
> response to H_SCM_HEALTH hcall. The details of the bit
> flags returned in response to this hcall is available
> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
> the flags reported in this sysfs file:
>
> kernel-doc reports:
>
> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
>
> and the output file Documentation/output/admin-guide/abi-testing.html says:
>
> response to H_SCM_HEALTH hcall. The details of the bit
> flags returned in response to this hcall is available
> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
> the flags reported in this sysfs file:</p>
>
>
> so the leading "Documentation/arch" is being removed from the filename
> AFAICT.
>
> I tried changing the quoted filename from single quotes to double back quotes
> `` and I tried it without any quotes, all with the same results.
>
I don't see that here, there is no warning and it renders properly.
If you go on https://docs.kernel.org/admin-guide/abi-testing.html then
it says 6.7.0-rc7 and (AFAICT) it also links/renders properly.
Maybe try building in a fresh clone/worktree just to verify there isn't
some old file somewhere that didn't get cleaned out/updated?
Vegard
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-27 7:55 docs: automarkup.py Randy Dunlap
2023-12-27 9:08 ` Vegard Nossum
@ 2023-12-27 11:42 ` Mauro Carvalho Chehab
1 sibling, 0 replies; 7+ messages in thread
From: Mauro Carvalho Chehab @ 2023-12-27 11:42 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Doc Mailing List, Jonathan Corbet, Vegard Nossum,
Nícolas F. R. A. Prado
Em Tue, 26 Dec 2023 23:55:26 -0800
Randy Dunlap <rdunlap@infradead.org> escreveu:
> Hi,
>
> Can anyone explain this? maybe even suggest a fix for it?
>
> This has been around for a few weeks AFAIK. I haven't see a patch for it,
> but I could have missed it.
>
> (since 17e02586ed185 in August/2023; oh, that just fixed the move
> of files to the Documentation/arch/ subdir, so maybe even longer)
>
>
> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
>
> response to H_SCM_HEALTH hcall. The details of the bit
> flags returned in response to this hcall is available
> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
> the flags reported in this sysfs file:
>
> kernel-doc reports:
>
> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
>
> and the output file Documentation/output/admin-guide/abi-testing.html says:
>
> response to H_SCM_HEALTH hcall. The details of the bit
> flags returned in response to this hcall is available
> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
> the flags reported in this sysfs file:</p>
With sphinx-build version 6.2.1 and latest linux-next, I'm getting:
<snip>
<p>Defined on file <a class="reference internal" href="#abi-file-testing-sysfs-bus-papr-pmem"><span class="std std-ref">sysfs-bus-papr-pmem</span></a></p>
<p>(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
more bits set in the dimm-health-bitmap retrieved in
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at '<a class="reference internal" href="../arch/powerpc/papr_hcalls.html"><span class="doc">Hypercall Op-codes (hcalls)</span></a>' .
</snip>
It seems that references are properly evaluated there.
> so the leading "Documentation/arch" is being removed from the filename
> AFAICT.
Actually, this is not related to automarkup.py, but, instead to
get_abi automation. You can see how this is processed by running
get_abi.pl script, e. g.:
<snip>
$ ./scripts/get_abi.pl search nmemX/papr/flags
/sys/bus/nd/devices/nmemX/papr/flags
------------------------------------
Kernel version: v5.8
Date: Apr, 2020
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Defined on file(s): Documentation/ABI/testing/sysfs-bus-papr-pmem
Description:
(RO) Report flags indicating various states of a
papr-pmem NVDIMM device. Each flag maps to a one or
more bits set in the dimm-health-bitmap retrieved in
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at 'Documentation/arch/powerpc/papr_hcalls.rst' . Below are
the flags reported in this sysfs file:
* "not_armed"
Indicates that NVDIMM contents will not
survive a power cycle.
* "flush_fail"
Indicates that NVDIMM contents
couldn't be flushed during last
shut-down event.
* "restore_fail"
Indicates that NVDIMM contents
couldn't be restored during NVDIMM
initialization.
* "encrypted"
NVDIMM contents are encrypted.
* "smart_notify"
There is health event for the NVDIMM.
* "scrubbed"
Indicating that contents of the
NVDIMM have been scrubbed.
* "locked"
Indicating that NVDIMM contents can't
be modified until next power cycle.
</snip>
The output there is not in ReST format. There is a "rest" parameter
to generate the version actually used by Sphinx.
When "./scripts/get_abi.pl rest" is used, it converts any reference
of Documentation/xxx.rst into[1]:
:doc:`/xxx`
Which is actually a relative link, pointing to the file at:
<doc_source_dir>/xxx.rst
The references there are relative to the doc root directory passed
to sphinx-build (Documentation/). So, the above shall create a
cross-reference to Documentation/xxx.rst using the document title as the
name of the reference, so this will become:
<a class="reference internal" href="../arch/powerpc/papr_hcalls.html"><span class="doc">Hypercall Op-codes (hcalls)</span></a>
[1] see https://docs.readthedocs.io/en/stable/guides/cross-referencing-with-sphinx.html#the-doc-role
See how a similar link is converted to ReST format:
<snip>
$ ./scripts/get_abi.pl rest |grep -A20 /mte_tcf_preferred
Warning: file Documentation/ABI/testing/sysfs-platform-silicom#20:
What '/sys/devices/platform/silicom-platform/power_cycle' doesn't have a description
| **\/sys\/devices\/system\/cpu\/cpuX\/mte_tcf_preferred** |
+----------------------------------------------------------+
Defined on file :ref:`sysfs-devices-system-cpu <abi_file_testing_sysfs_devices_system_cpu>`
Preferred MTE tag checking mode
When a user program specifies more than one MTE tag checking
mode, this sysfs node is used to specify which mode should
be preferred when scheduling a task on that CPU. Possible
values:
================ ==============================================
"sync" Prefer synchronous mode
"asymm" Prefer asymmetric mode
"async" Prefer asynchronous mode
================ ==============================================
See also: :doc:`/arch/arm64/memory-tagging-extension`
<snip>
> I tried changing the quoted filename from single quotes to double back quotes
> `` and I tried it without any quotes, all with the same results.
With a quote like "`", the above would be evaluated to:
See also: `:doc:`/arch/arm64/memory-tagging-extension``
which will probably cause problems when sphinx parses it.
That's said, I remember that some old Sphinx versions had issues
with the doc: tag. On some legacy versions, the <doc_source_dir>
is set in a wrong way, ignoring the path used at the sphinx-build
directory parameter.
Thanks,
Mauro
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-27 9:08 ` Vegard Nossum
@ 2023-12-27 22:20 ` Randy Dunlap
2023-12-28 16:22 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2023-12-27 22:20 UTC (permalink / raw)
To: Vegard Nossum, Linux Doc Mailing List
Cc: Jonathan Corbet, Nícolas F. R. A. Prado, Mauro Carvalho Chehab
Hi Vegard and Mauro,
Thanks for your assistance.
(more below)
On 12/27/23 01:08, Vegard Nossum wrote:
>
> On 27/12/2023 08:55, Randy Dunlap wrote:
>> Can anyone explain this? maybe even suggest a fix for it?
>>
>> This has been around for a few weeks AFAIK. I haven't see a patch for it,
>> but I could have missed it.
>>
>> (since 17e02586ed185 in August/2023; oh, that just fixed the move
>> of files to the Documentation/arch/ subdir, so maybe even longer)
>>
>>
>> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
>>
>> response to H_SCM_HEALTH hcall. The details of the bit
>> flags returned in response to this hcall is available
>> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
>> the flags reported in this sysfs file:
>>
>> kernel-doc reports:
>>
>> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
>>
>> and the output file Documentation/output/admin-guide/abi-testing.html says:
>>
>> response to H_SCM_HEALTH hcall. The details of the bit
>> flags returned in response to this hcall is available
>> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
>> the flags reported in this sysfs file:</p>
>>
>>
>> so the leading "Documentation/arch" is being removed from the filename
>> AFAICT.
>>
>> I tried changing the quoted filename from single quotes to double back quotes
>> `` and I tried it without any quotes, all with the same results.
>>
>
> I don't see that here, there is no warning and it renders properly.
>
> If you go on https://docs.kernel.org/admin-guide/abi-testing.html then
> it says 6.7.0-rc7 and (AFAICT) it also links/renders properly.
Yes, I probably should have checked there earlier. :)
> Maybe try building in a fresh clone/worktree just to verify there isn't
> some old file somewhere that didn't get cleaned out/updated?
That does work but it made me suspicious.
I was building in a kernel tree that was built from a tarball
and linux-next daily patches. That leaves behind some *.orig files
(since I use 'patch -b' for "backups").
If I remove the Documentation/ABI/*.orig files, there is no issue
like I had erroneously reported here.
Maybe get_abi.pl is (also) processing the *.orig files and that
somehow causes it to produce the confusing output.
Anyway, nothing to see here. Move along. :)
Thanks again.
--
#Randy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-27 22:20 ` Randy Dunlap
@ 2023-12-28 16:22 ` Mauro Carvalho Chehab
2023-12-28 20:01 ` Randy Dunlap
0 siblings, 1 reply; 7+ messages in thread
From: Mauro Carvalho Chehab @ 2023-12-28 16:22 UTC (permalink / raw)
To: Randy Dunlap
Cc: Vegard Nossum, Linux Doc Mailing List, Jonathan Corbet,
Nícolas F. R. A. Prado
Em Wed, 27 Dec 2023 14:20:05 -0800
Randy Dunlap <rdunlap@infradead.org> escreveu:
> Hi Vegard and Mauro,
>
> Thanks for your assistance.
> (more below)
>
>
> On 12/27/23 01:08, Vegard Nossum wrote:
> >
> > On 27/12/2023 08:55, Randy Dunlap wrote:
> >> Can anyone explain this? maybe even suggest a fix for it?
> >>
> >> This has been around for a few weeks AFAIK. I haven't see a patch for it,
> >> but I could have missed it.
> >>
> >> (since 17e02586ed185 in August/2023; oh, that just fixed the move
> >> of files to the Documentation/arch/ subdir, so maybe even longer)
> >>
> >>
> >> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
> >>
> >> response to H_SCM_HEALTH hcall. The details of the bit
> >> flags returned in response to this hcall is available
> >> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
> >> the flags reported in this sysfs file:
> >>
> >> kernel-doc reports:
> >>
> >> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
> >>
> >> and the output file Documentation/output/admin-guide/abi-testing.html says:
> >>
> >> response to H_SCM_HEALTH hcall. The details of the bit
> >> flags returned in response to this hcall is available
> >> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
> >> the flags reported in this sysfs file:</p>
> >>
> >>
> >> so the leading "Documentation/arch" is being removed from the filename
> >> AFAICT.
> >>
> >> I tried changing the quoted filename from single quotes to double back quotes
> >> `` and I tried it without any quotes, all with the same results.
> >>
> >
> > I don't see that here, there is no warning and it renders properly.
> >
> > If you go on https://docs.kernel.org/admin-guide/abi-testing.html then
> > it says 6.7.0-rc7 and (AFAICT) it also links/renders properly.
>
> Yes, I probably should have checked there earlier. :)
>
> > Maybe try building in a fresh clone/worktree just to verify there isn't
> > some old file somewhere that didn't get cleaned out/updated?
>
> That does work but it made me suspicious.
>
> I was building in a kernel tree that was built from a tarball
> and linux-next daily patches. That leaves behind some *.orig files
> (since I use 'patch -b' for "backups").
>
> If I remove the Documentation/ABI/*.orig files, there is no issue
> like I had erroneously reported here.
> Maybe get_abi.pl is (also) processing the *.orig files and that
> somehow causes it to produce the confusing output.
The logic which parse files at get_abi.pl is this one:
sub parse_abi {
my $file = $File::Find::name;
my $mode = (stat($file))[2];
return if ($mode & S_IFDIR);
return if ($file =~ m,/README,);
Currently, it ignores just README and directories.
It wouldn't be hard to add something like:
return if ($file =~ m,/\.(rej|org|orig|bak)$,);
to ignore certain extensions. On such case, we would need to explicitly
add the extensions to be Ignored.
We could, instead, do a broader regex:
return if ($file =~ m,/\.,);
to ignore everything that would have a dot at the file name, but that
could be problematic if we ever end adding files with extensions
there.
Regards,
Mauro
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-28 16:22 ` Mauro Carvalho Chehab
@ 2023-12-28 20:01 ` Randy Dunlap
2023-12-28 20:12 ` Mauro Carvalho Chehab
0 siblings, 1 reply; 7+ messages in thread
From: Randy Dunlap @ 2023-12-28 20:01 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Vegard Nossum, Linux Doc Mailing List, Jonathan Corbet,
Nícolas F. R. A. Prado
On 12/28/23 08:22, Mauro Carvalho Chehab wrote:
> Em Wed, 27 Dec 2023 14:20:05 -0800
> Randy Dunlap <rdunlap@infradead.org> escreveu:
>
>> Hi Vegard and Mauro,
>>
>> Thanks for your assistance.
>> (more below)
>>
>>
>> On 12/27/23 01:08, Vegard Nossum wrote:
>>>
>>> On 27/12/2023 08:55, Randy Dunlap wrote:
>>>> Can anyone explain this? maybe even suggest a fix for it?
>>>>
>>>> This has been around for a few weeks AFAIK. I haven't see a patch for it,
>>>> but I could have missed it.
>>>>
>>>> (since 17e02586ed185 in August/2023; oh, that just fixed the move
>>>> of files to the Documentation/arch/ subdir, so maybe even longer)
>>>>
>>>>
>>>> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
>>>>
>>>> response to H_SCM_HEALTH hcall. The details of the bit
>>>> flags returned in response to this hcall is available
>>>> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
>>>> the flags reported in this sysfs file:
>>>>
>>>> kernel-doc reports:
>>>>
>>>> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
>>>>
>>>> and the output file Documentation/output/admin-guide/abi-testing.html says:
>>>>
>>>> response to H_SCM_HEALTH hcall. The details of the bit
>>>> flags returned in response to this hcall is available
>>>> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
>>>> the flags reported in this sysfs file:</p>
>>>>
>>>>
>>>> so the leading "Documentation/arch" is being removed from the filename
>>>> AFAICT.
>>>>
>>>> I tried changing the quoted filename from single quotes to double back quotes
>>>> `` and I tried it without any quotes, all with the same results.
>>>>
>>>
>>> I don't see that here, there is no warning and it renders properly.
>>>
>>> If you go on https://docs.kernel.org/admin-guide/abi-testing.html then
>>> it says 6.7.0-rc7 and (AFAICT) it also links/renders properly.
>>
>> Yes, I probably should have checked there earlier. :)
>>
>>> Maybe try building in a fresh clone/worktree just to verify there isn't
>>> some old file somewhere that didn't get cleaned out/updated?
>>
>> That does work but it made me suspicious.
>>
>> I was building in a kernel tree that was built from a tarball
>> and linux-next daily patches. That leaves behind some *.orig files
>> (since I use 'patch -b' for "backups").
>>
>> If I remove the Documentation/ABI/*.orig files, there is no issue
>> like I had erroneously reported here.
>> Maybe get_abi.pl is (also) processing the *.orig files and that
>> somehow causes it to produce the confusing output.
>
> The logic which parse files at get_abi.pl is this one:
>
> sub parse_abi {
> my $file = $File::Find::name;
>
> my $mode = (stat($file))[2];
> return if ($mode & S_IFDIR);
> return if ($file =~ m,/README,);
>
> Currently, it ignores just README and directories.
>
> It wouldn't be hard to add something like:
>
> return if ($file =~ m,/\.(rej|org|orig|bak)$,);
That didn't quite work as is. I changed it to this:
+ return if ($file =~ m,\.(rej|org|orig|bak)$,);
which works (dropping the leading "/").
> to ignore certain extensions. On such case, we would need to explicitly
> add the extensions to be Ignored.
>
> We could, instead, do a broader regex:
>
> return if ($file =~ m,/\.,);
That line is already present in the script, for skipping
hidden (dot) files.
It does not skip filenames like "papr_hcalls.orig" -- at least I
still see this problem when that line is present.
I wouldn't suggest skipping any file that has a '.' in its name.
>
> to ignore everything that would have a dot at the file name, but that
> could be problematic if we ever end adding files with extensions
> there.
>
> Regards,
> Mauro
>
Thanks.
--
#Randy
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: docs: automarkup.py
2023-12-28 20:01 ` Randy Dunlap
@ 2023-12-28 20:12 ` Mauro Carvalho Chehab
0 siblings, 0 replies; 7+ messages in thread
From: Mauro Carvalho Chehab @ 2023-12-28 20:12 UTC (permalink / raw)
To: Randy Dunlap
Cc: Vegard Nossum, Linux Doc Mailing List, Jonathan Corbet,
Nícolas F. R. A. Prado
Em Thu, 28 Dec 2023 12:01:00 -0800
Randy Dunlap <rdunlap@infradead.org> escreveu:
> On 12/28/23 08:22, Mauro Carvalho Chehab wrote:
> > Em Wed, 27 Dec 2023 14:20:05 -0800
> > Randy Dunlap <rdunlap@infradead.org> escreveu:
> >
> >> Hi Vegard and Mauro,
> >>
> >> Thanks for your assistance.
> >> (more below)
> >>
> >>
> >> On 12/27/23 01:08, Vegard Nossum wrote:
> >>>
> >>> On 27/12/2023 08:55, Randy Dunlap wrote:
> >>>> Can anyone explain this? maybe even suggest a fix for it?
> >>>>
> >>>> This has been around for a few weeks AFAIK. I haven't see a patch for it,
> >>>> but I could have missed it.
> >>>>
> >>>> (since 17e02586ed185 in August/2023; oh, that just fixed the move
> >>>> of files to the Documentation/arch/ subdir, so maybe even longer)
> >>>>
> >>>>
> >>>> In file Documentation/ABI/testing/sysfs-bus-papr-pmem:
> >>>>
> >>>> response to H_SCM_HEALTH hcall. The details of the bit
> >>>> flags returned in response to this hcall is available
> >>>> at 'Documentation/arch/powerpc/papr_hcalls.rst'. Below are
> >>>> the flags reported in this sysfs file:
> >>>>
> >>>> kernel-doc reports:
> >>>>
> >>>> linux-next-20231222/Documentation/ABI/testing/sysfs-bus-papr-pmem:2: WARNING: unknown document: '/powerpc/papr_hcalls'
> >>>>
> >>>> and the output file Documentation/output/admin-guide/abi-testing.html says:
> >>>>
> >>>> response to H_SCM_HEALTH hcall. The details of the bit
> >>>> flags returned in response to this hcall is available
> >>>> at '<span class="xref std std-doc">/powerpc/papr_hcalls</span>' . Below are
> >>>> the flags reported in this sysfs file:</p>
> >>>>
> >>>>
> >>>> so the leading "Documentation/arch" is being removed from the filename
> >>>> AFAICT.
> >>>>
> >>>> I tried changing the quoted filename from single quotes to double back quotes
> >>>> `` and I tried it without any quotes, all with the same results.
> >>>>
> >>>
> >>> I don't see that here, there is no warning and it renders properly.
> >>>
> >>> If you go on https://docs.kernel.org/admin-guide/abi-testing.html then
> >>> it says 6.7.0-rc7 and (AFAICT) it also links/renders properly.
> >>
> >> Yes, I probably should have checked there earlier. :)
> >>
> >>> Maybe try building in a fresh clone/worktree just to verify there isn't
> >>> some old file somewhere that didn't get cleaned out/updated?
> >>
> >> That does work but it made me suspicious.
> >>
> >> I was building in a kernel tree that was built from a tarball
> >> and linux-next daily patches. That leaves behind some *.orig files
> >> (since I use 'patch -b' for "backups").
> >>
> >> If I remove the Documentation/ABI/*.orig files, there is no issue
> >> like I had erroneously reported here.
> >> Maybe get_abi.pl is (also) processing the *.orig files and that
> >> somehow causes it to produce the confusing output.
> >
> > The logic which parse files at get_abi.pl is this one:
> >
> > sub parse_abi {
> > my $file = $File::Find::name;
> >
> > my $mode = (stat($file))[2];
> > return if ($mode & S_IFDIR);
> > return if ($file =~ m,/README,);
> >
> > Currently, it ignores just README and directories.
> >
> > It wouldn't be hard to add something like:
> >
> > return if ($file =~ m,/\.(rej|org|orig|bak)$,);
>
> That didn't quite work as is. I changed it to this:
>
> + return if ($file =~ m,\.(rej|org|orig|bak)$,);
>
> which works (dropping the leading "/").
Great! If you want, feel free to submit a patch with that with
my Acked-by.
>
> > to ignore certain extensions. On such case, we would need to explicitly
> > add the extensions to be Ignored.
> >
> > We could, instead, do a broader regex:
> >
> > return if ($file =~ m,/\.,);
>
> That line is already present in the script, for skipping
> hidden (dot) files.
>
> It does not skip filenames like "papr_hcalls.orig" -- at least I
> still see this problem when that line is present.
>
> I wouldn't suggest skipping any file that has a '.' in its name.
Yeah, agreed.
Regards,
Mauro
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2023-12-28 20:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-27 7:55 docs: automarkup.py Randy Dunlap
2023-12-27 9:08 ` Vegard Nossum
2023-12-27 22:20 ` Randy Dunlap
2023-12-28 16:22 ` Mauro Carvalho Chehab
2023-12-28 20:01 ` Randy Dunlap
2023-12-28 20:12 ` Mauro Carvalho Chehab
2023-12-27 11:42 ` Mauro Carvalho Chehab
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.