linux-kernel - Re: [PATCH 0/2] Move kernel-doc to tools/docs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260117110049.6cc49048@foz.lan>
Date: Sat, 17 Jan 2026 11:00:49 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Jonathan Corbet <corbet@....net>
Cc: Randy Dunlap <rdunlap@...radead.org>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, Akira Yokosawa <akiyks@...il.com>, Shuah Khan
 <shuah@...nel.org>, Jani Nikula <jani.nikula@...ux.intel.com>
Subject: Re: [PATCH 0/2] Move kernel-doc to tools/docs

Em Fri, 16 Jan 2026 10:48:51 -0700
Jonathan Corbet <corbet@....net> escreveu:

> Mauro Carvalho Chehab <mchehab+huawei@...nel.org> writes:
> 
> > Em Wed, 14 Jan 2026 12:24:31 -0700
> > Jonathan Corbet <corbet@....net> escreveu:
> >  
> >> Randy Dunlap <rdunlap@...radead.org> writes:
> >>   
> >> > I do many of these on a regular basis:
> >> >
> >> > $ ./scripts/kernel-doc -none -Wall <path_to_source_file>
> >> >
> >> > Will I still be able to do that (by using ./tools/doc/kernel-doc ...)?    
> >> 
> >> Yes.  The tool moves, but its functionality remains unchanged.  
> >
> > That's actually a good point: should we preserve a link on scripts
> > pointing to ../tools/doc/kernel-doc? I suspect that a change like
> > that could break some machinery on several CI tools and scripts
> > out there. If so, it could be useful to keep a link - at least for
> > a couple of kernel releases.  
> 
> So is the location of kernel-doc part of our ABI, or an internal detail?
> :)

Surely it is not part of ABI: it can be changed whenever we want.

From my side, I don't mind where it is located: it will take some
time, but my fingers will end learning its new location/name ;-)

> I'm not deeply opposed to maintaining the symlink, though I'd rather
> not.  It won't be for "a couple of releases", though; if the symlink is
> there, nothing will ever change.

I see two reasons why having a symlink:

1. to avoid the risk of eventually breaking someone's CI or scripts.
   This is just a preventive measure, as I'm not aware of anyone
   with such scripts;

2. as you don't want ".py" extension on execs, but PEP8 mandates it, 
   together with replacing "-" with "_", you can have a symlink that
   would make both PEP8 and you happy ;-)

Just my 2 cents.


Thanks,
Mauro