Handling deprecated syscalls on Linux

[Dave Cheney]

TL;DR linux/arm64 doesn't provide a lot of legacy syscalls, so some
changes need to be made to the syscall package (non API breaking)
before the arm64 port can be merged.

Hello,

Arm64 is the first platform to remove many "legacy" syscalls. These
syscalls are handled by libc and forwarded to their modern
replacement. As we don't use libc we have to do this ourselves in the
syscall package.

The list of syscalls that need to be handled is roughly

https://github.com/4ad/go/commit/f97de67c7f843650cc913643ee60b1d97189ca48#diff-edb465e600d9d639a74a3314e8bc7b20R96

There are three main approaches to address this.

1. Where the syscall has grown a new final argument, usually a flag or
pointer to an unused structure, use the = REPLACEMENT syntax that
./mksyscall.pl supports. This is used for select(2) in many places
already. An example is

https://github.com/4ad/go/commit/823f3a1903da7fbc872b95fcec895384dac90a72

2. For the *at style syscalls, forward, for example, syscall.Open, to
syscall.OpenAt and provide the magic AT_FDCWD argument. An example
(ignore the fact I didn't know AT_FDCWD wasn't already defined) would
be

https://github.com/4ad/go/commit/eb9af0cf2aa0b275291b800dddc35584c4f76cbe

3. The last group are syscalls which are used internally by the
syscall package or have well known replacements already in use,
dup2/dup3 and pipe/pipe2 are good examples. A sample of the type of
fix to be applied would be

https://github.com/4ad/go/commit/f27c44bb23902bcadf2043aaee5157297d8f0275

I would like to propose applying these methods to the syscall package
as it exists today to avoid having to duplicate a lot of logic in the
existing linux_$GOOS_$GOARCH.go files during the arm64 merge.

I am looking for comments or support for this proposal.

Thank you for your time

Dave

[Ian Lance Taylor]

On Mon, Feb 23, 2015 at 10:11 PM, Dave Cheney <da...@cheney.net> wrote:
>
> 1. Where the syscall has grown a new final argument, usually a flag or
> pointer to an unused structure, use the = REPLACEMENT syntax that
> ./mksyscall.pl supports. This is used for select(2) in many places
> already. An example is
>
> https://github.com/4ad/go/commit/823f3a1903da7fbc872b95fcec895384dac90a72

This will work fine provided the generated Go function does not have
exactly 3 or 6 parameters. The syscall package is so specialized that
maybe that limitation is OK, but we definitely need to be aware of it.

> 2. For the *at style syscalls, forward, for example, syscall.Open, to
> syscall.OpenAt and provide the magic AT_FDCWD argument. An example
> (ignore the fact I didn't know AT_FDCWD wasn't already defined) would
> be
>
> https://github.com/4ad/go/commit/eb9af0cf2aa0b275291b800dddc35584c4f76cbe

SGTM.

> 3. The last group are syscalls which are used internally by the
> syscall package or have well known replacements already in use,
> dup2/dup3 and pipe/pipe2 are good examples. A sample of the type of
> fix to be applied would be
>
> https://github.com/4ad/go/commit/f27c44bb23902bcadf2043aaee5157297d8f0275

pipe2 and dup3 were added in kernel version 2.6.27. We currently
support kernels back to 2.6.23. So here you are implicitly arguing
for bumping the supported kernel version number. That needs to be
discussed separately. I personally have no idea of what that would
imply--actually I don't even remember how we picked 2.6.23 in the
first place.

Ian

[Aram Hăvărneanu]

FWIW, all the .*at syscalls were added in 2.6.16, so only pipe2 and
dup3 are problematic.

--
Aram Hăvărneanu

[Dave Cheney]

Thanks for your response Ian

On Wed, Feb 25, 2015 at 6:04 AM, Ian Lance Taylor <ia...@golang.org> wrote:
> On Mon, Feb 23, 2015 at 10:11 PM, Dave Cheney <da...@cheney.net> wrote:
>>
>> 1. Where the syscall has grown a new final argument, usually a flag or
>> pointer to an unused structure, use the = REPLACEMENT syntax that
>> ./mksyscall.pl supports. This is used for select(2) in many places
>> already. An example is
>>
>> https://github.com/4ad/go/commit/823f3a1903da7fbc872b95fcec895384dac90a72
>
> This will work fine provided the generated Go function does not have
> exactly 3 or 6 parameters. The syscall package is so specialized that
> maybe that limitation is OK, but we definitely need to be aware of it.

I'll tackle this one last. It may make sense to use a forwarding
method depending on the situation.

>> 2. For the *at style syscalls, forward, for example, syscall.Open, to
>> syscall.OpenAt and provide the magic AT_FDCWD argument. An example
>> (ignore the fact I didn't know AT_FDCWD wasn't already defined) would
>> be
>>
>> https://github.com/4ad/go/commit/eb9af0cf2aa0b275291b800dddc35584c4f76cbe
>
> SGTM.

Thank you, I'll send a PR for this first as it is the most straight forward.

>> 3. The last group are syscalls which are used internally by the
>> syscall package or have well known replacements already in use,
>> dup2/dup3 and pipe/pipe2 are good examples. A sample of the type of
>> fix to be applied would be
>>
>> https://github.com/4ad/go/commit/f27c44bb23902bcadf2043aaee5157297d8f0275
>
> pipe2 and dup3 were added in kernel version 2.6.27. We currently
> support kernels back to 2.6.23. So here you are implicitly arguing
> for bumping the supported kernel version number. That needs to be
> discussed separately. I personally have no idea of what that would
> imply--actually I don't even remember how we picked 2.6.23 in the
> first place.

I'll send a PR that breaks out the use of syscall.pipe to individual
syscall_linux_$GOARCH.go files so we can retain pipe and dup2 for
intel (kernel 2.6.23), and switch to pipe2/dup3 for arm (kernel
2.6.27), and ppc64 and arm64 (which are high 3.x series)

Thanks

Dave