To split or not to split a syscall implementation from its wireup?

To split or not to split a syscall implementation from its wireup?

[David Howells]

Hi Linus,

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?

Thanks,
David

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

[Linus Torvalds]

On Mon, Mar 16, 2020 at 8:49 AM David Howells <dhowells@redhat.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