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  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]
Date:   Mon, 23 Jan 2017 11:44:54 +0100
From:   Geert Uytterhoeven <>
To:     Mauro Carvalho Chehab <>
Cc:     Joe Perches <>, Jonathan Corbet <>,
        "" <>,
        "" <>
Subject: Re: [PATCH] docs: Make CodingStyle and SubmittingPatches symlinks

Hi Mauro,

On Mon, Jan 23, 2017 at 11:34 AM, Mauro Carvalho Chehab
<> wrote:
> Em Fri, 13 Jan 2017 12:03:24 -0800
> Joe Perches <> escreveu:
>> On Fri, 2017-01-13 at 12:41 -0700, Jonathan Corbet wrote:
>> > On Tue, 10 Jan 2017 14:09:51 -0800
>> > Joe Perches <> wrote:
>> >
>> > > Make these files symlinks to the .rst equivalents
>> >
>> > So I am not necessarily opposed to doing this, but the changelog lacks
>> > one important thing: why do we need to make that change?  Have the
>> > existing one-liner files been a problem somehow?
>> The files tell people to open other files.
>> Giving the old link to people just tells them to
>> use the new filename instead.
>> symlinks open the new file automatically.
>> $ head Documentation/CodingStyle
>> This file has moved to process/coding-style.rst
>> vs a symlink
>> $ head Documentation/CodingStyle
>> .. _codingstyle:
>> Linux kernel coding style
>> =========================
>> This is a short document describing the preferred coding style for the
>> linux kernel.  Coding style is very personal, and I won't **force** my
>> views on anybody, but this is what goes for anything that I have to be
>> able to maintain, and I'd prefer it for most other things too.  Please
>> at least consider the points made here.
> IMHO, we should either use symlinks or files with "replaced by" contents.
> The main difference between a "pointer file" and a symlink is that the
> first indicates a temporary solution, teaching people that the
> file got renamed and were it is located now. As such, we can remove
> those "pointer files" on some future Kernel releases without much concern.
> A symlink indicates a more permanent situation, as people will keep
> using the symlinked files as before. That means that any attempt to
> remove those in the future will generate concerns.

Agreed, about temporary vs. permanent.

> So, I'm in favor of using the "pointer files" instead, as it
> gives us an easier way to get rid of them when we find convenient.

When will/can we get rid of them?
Old (doh) kernels, and new versions of stable kernels will keep on having
them for the next +10 years.

To me, these[*] filenames are more like a user-visible API, which should
not be changed without given consideration.

[*] CodingStyle and SubmittingPatches (there may be others) are linked from
    many web pages and email archives.
    Anyone looked at how many links Google thinks there are?



Geert Uytterhoeven -- There's lots of Linux beyond ia32 --

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Powered by blists - more mailing lists