Remove parameter 'segflg' from the function *exec_copyin_args

[wy-chung]

In kernel "copyin" means copy data from user address space to kernel address space. But in the function *exec_copyin_args there is a parameter 'segflg' that is used to specify the address space of the parameter 'fname'. In the source code there are two places where 'segflg' are not UIO_USERSPACE. In both cases the 'fname' argument are NULL so the argument 'segflg' are not important there. So it is safe to remove the parameter 'segflg' from the function *exec_copyin_args.

[markjdb]

This looks ok to me.

I don't think it makes sense to have the extra commit to wrap a long line - this can be done in the main commit since you are modifying that line already.

[bsdjhb]

Hmmm, we do have a UIO_SYSSPACE fname when starting the init process (pid 1), but I think there we don't call exec_copyin_args() but construct the args directly. Hmm, seems even before that change (commit 3a325de) we were still getting the fname from userspace in that case.

I think this is fine.

[wy-chung]

This looks ok to me.

I don't think it makes sense to have the extra commit to wrap a long line - this can be done in the main commit since you are modifying that line already.

I send the pull request and then I receive a email from the github. It says that a line is too long so I send a second commit. I don't know how to change the oroginal pull request. This is the only way I know how to fix this error.

[markjdb]

This looks ok to me.
I don't think it makes sense to have the extra commit to wrap a long line - this can be done in the main commit since you are modifying that line already.

I send the pull request and then I receive a email from the github. It says that a line is too long so I send a second commit. I don't know how to change the oroginal pull request. This is the only way I know how to fix this error.

To modify the most recent commit, you can stage changes as normal and run git commit --amend. More generally, you can use git rebase to "squash" commits together into one. Then, force-push your branch to update this pull request.

Using git rebase to do this requires some practice. I can squash the commits for this PR if you like, but for next time, it's worth learning how to amend and squash commits.