Drop the "created from" line from files generated by makesyscalls.sh.

[jhb]

Summary

This information is less useful when the generated files are included in
source control along with the source. If needed it can be reconstructed
from the $FreeBSD$ tag in the generated file. Including this information
in the generated output results in the awkward workflow where the generated
files are committed as a separate commit from the change to the system call
master list.

Note: as a followup commit it might make sense to merge the BEGIN and
NR == 1 clauses so all of the per-file initialization is done in one place.

Test Plan

• Run 'make sysent' in sys/kern and verify the only output changed is the removal of the 'created from' comment lines.

[kib]

What you characterized as awkward workflow is quite useful IMO. I mean that review of the patches which mix actual changes, with the generated files, is practically impossible, the generated bits must be removed before the patch becomes more readable. Same note holds for reading VCS diff when looking at the history. In other words, I very much appreciate the workflow where generated files are committed later.

[emaste]

This is fine with me.

[jhb]

In D9497#196227, @kib wrote:

What you characterized as awkward workflow is quite useful IMO. I mean that review of the patches which mix actual changes, with the generated files, is practically impossible, the generated bits must be removed before the patch becomes more readable. Same note holds for reading VCS diff when looking at the history. In other words, I very much appreciate the workflow where generated files are committed later.

The downsides I see are that 1) I tend to test my work branches on a different machine where I do the editing, so I generally end up doing the 'make sysent' in my git branches anyway so the changes are pushed to the remote machines, and 2) especially for MFCs I don't like having the tree in a known-broken state. I'd rather the entire change to add or modify a syscall be an atomic change. I do think that in some cases not having this one line change will actually reduce the noise in the diffs as well. Most of the time when I change an existing system call (e.g. Brooks recently changing a u_int to a size_t in an arg), most of the noise in the diff is due to the "created by" lines changing (in some cases that is the only change in the relevant files).

[kib]

In D9497#196911, @jhb wrote:

In D9497#196227, @kib wrote:

What you characterized as awkward workflow is quite useful IMO. I mean that review of the patches which mix actual changes, with the generated files, is practically impossible, the generated bits must be removed before the patch becomes more readable. Same note holds for reading VCS diff when looking at the history. In other words, I very much appreciate the workflow where generated files are committed later.

The downsides I see are that 1) I tend to test my work branches on a different machine where I do the editing, so I generally end up doing the 'make sysent' in my git branches anyway so the changes are pushed to the remote machines, and 2) especially for MFCs I don't like having the tree in a known-broken state. I'd rather the entire change to add or modify a syscall be an atomic change. I do think that in some cases not having this one line change will actually reduce the noise in the diffs as well. Most of the time when I change an existing system call (e.g. Brooks recently changing a u_int to a size_t in an arg), most of the noise in the diff is due to the "created by" lines changing (in some cases that is the only change in the relevant files).

As you see, I do not disagree with the change, already accepted it. Also I do not disagree with change of policy to start require make sysent on stable branches to be committed together with the real change. What I do not like is the HEAD commits mixing code and generated files.

Real solution is, of course, to change libc build procedure and header installation to generate needed files at build stage, so that kernel can treat syscall.master files same as e.g. vnode_if.src. Then the regenerated files can be pruned from the repo at all.

[jhb]

In D9497#196922, @kib wrote:

In D9497#196911, @jhb wrote:

In D9497#196227, @kib wrote:

What you characterized as awkward workflow is quite useful IMO. I mean that review of the patches which mix actual changes, with the generated files, is practically impossible, the generated bits must be removed before the patch becomes more readable. Same note holds for reading VCS diff when looking at the history. In other words, I very much appreciate the workflow where generated files are committed later.

The downsides I see are that 1) I tend to test my work branches on a different machine where I do the editing, so I generally end up doing the 'make sysent' in my git branches anyway so the changes are pushed to the remote machines, and 2) especially for MFCs I don't like having the tree in a known-broken state. I'd rather the entire change to add or modify a syscall be an atomic change. I do think that in some cases not having this one line change will actually reduce the noise in the diffs as well. Most of the time when I change an existing system call (e.g. Brooks recently changing a u_int to a size_t in an arg), most of the noise in the diff is due to the "created by" lines changing (in some cases that is the only change in the relevant files).

As you see, I do not disagree with the change, already accepted it. Also I do not disagree with change of policy to start require make sysent on stable branches to be committed together with the real change. What I do not like is the HEAD commits mixing code and generated files.

Real solution is, of course, to change libc build procedure and header installation to generate needed files at build stage, so that kernel can treat syscall.master files same as e.g. vnode_if.src. Then the regenerated files can be pruned from the repo at all.

Hmm, I think I'm fine with that (generating them all at build time). I think only some of the headers are installed for userland (the main kernel ones, but not any of the headers for compat ABIs AFAIK).