linux-kernel - Re: To split or not to split a syscall implementation from its wireup?

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] [day] [month] [year] [list]

Message-ID: <CAHk-=wih0Uq8CB+wk1heOobmS3Yuehnp5bqx=4fj=chzAHJoLw@mail.gmail.com>
Date:   Mon, 16 Mar 2020 10:33:10 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     David Howells <dhowells@...hat.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: To split or not to split a syscall implementation from its wireup?

On Mon, Mar 16, 2020 at 8:49 AM David Howells <dhowells@...hat.com> wrote:
>
> When it comes to creating a new system call, do you have a preference as to
> whether the system call implementation should be in the same patch as the
> wire-up or is it preferable that the two be split into separate patches?

It depends.

If it's "new code that has no other use than the system call", then
splitting it up is pointless: you'll just have a commit with dead code
first and no test coverage, and then a commit that adds the system
call. If it results in the problems, the new system call commit is the
one that gets fingered as the problematic one, but it doesn't actually
really _do_ anything.

However, if adding a new system call is preceded by first
re-organizing existing code so that you have the infrastructure set up
for the new system call, then that re-organization should be done
separately, and then one commit that just adds the new system call
that uses the newly organized code.  In fact, in that case if the new
organization is at all subtle, I'd prefer not just splitting it, but
waiting a bit before adding the new system call - because if the
changes cause problems, then the reord may be fundamentally broken and
maybe the new system call isn't even worth the pain at all.

So the difference is that in that second case, testing the
re-organized code on its own is meaningful (and arguably more
important than the new system call, since it's a potential for
regression on its own).

            Linus