code review 96970043: syscall: regenerate z-files for openbsd

syscall: regenerate z-files for openbsd

This CL restores dropped constants not supported in OpenBSD 5.5
and tris to keep the promise of API compatibility.

Update issue 7049

[mikio, 2014-05-02 14:46:32]

Hello rsc@golang.org, jsing@google.com (cc:
golang-codereviews@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[mikio, 2014-05-02 15:17:13]

fyi: confirmed go1.3 w/ this cl works well on openbsd 5.5 which is
released yesterday.

On Fri, May 2, 2014 at 11:46 PM,  <mikioh.mikioh@gmail.com> wrote:
> Reviewers: rsc, jsing,
>
> Message:
> Hello rsc@golang.org, jsing@google.com (cc:
> golang-codereviews@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go
>
>
> Description:
> syscall: regenerate z-files for openbsd 5.5
>
> Update issue 7049
>
> Please review this at https://codereview.appspot.com/96970043/
>
> Affected files (+1, -2 lines):
>   M src/pkg/syscall/zerrors_openbsd_386.go
>   M src/pkg/syscall/zerrors_openbsd_amd64.go
>
>
> Index: src/pkg/syscall/zerrors_openbsd_386.go
> ===================================================================
> --- a/src/pkg/syscall/zerrors_openbsd_386.go
> +++ b/src/pkg/syscall/zerrors_openbsd_386.go
> @@ -1228,6 +1228,7 @@
>         TIOCGETD                          = 0x4004741a
>         TIOCGFLAGS                        = 0x4004745d
>         TIOCGPGRP                         = 0x40047477
> +       TIOCGSID                          = 0x40047463
>         TIOCGTSTAMP                       = 0x400c745b
>         TIOCGWINSZ                        = 0x40087468
>         TIOCMBIC                          = 0x8004746b
> @@ -1296,7 +1297,6 @@
>         VSUSP                             = 0xa
>         VTIME                             = 0x11
>         VWERASE                           = 0x4
> -       WALTSIG                           = 0x4
>         WCONTINUED                        = 0x8
>         WCOREFLAG                         = 0x80
>         WNOHANG                           = 0x1
> Index: src/pkg/syscall/zerrors_openbsd_amd64.go
> ===================================================================
> --- a/src/pkg/syscall/zerrors_openbsd_amd64.go
> +++ b/src/pkg/syscall/zerrors_openbsd_amd64.go
> @@ -1296,7 +1296,6 @@
>         VSUSP                             = 0xa
>         VTIME                             = 0x11
>         VWERASE                           = 0x4
> -       WALTSIG                           = 0x4
>         WCONTINUED                        = 0x8
>         WCOREFLAG                         = 0x80
>         WNOHANG                           = 0x1
>
>

[jsing, 2014-05-02 16:04:51]

LGTM but please wait for rsc.

(I'm not sure where things are at with the 1.3 release and this is annoying
rather than critical).

TIOCGSID was readded to sys/ttycom.h in r1.13
WALTSIG was removed from sys/wait.h in r1.16

Thanks.

[rsc, 2014-05-02 16:18:08]

Was WALTSIG in the 1.2 release? If so, please keep it here.

[rh, 2014-05-02 17:02:56]

On 2014/05/02 16:18:08, rsc wrote:
> Was WALTSIG in the 1.2 release? If so, please keep it here.

Yes, it was in 1.2.

[minux1, 2014-05-02 17:18:07]

I think this should wait until 1.4.
OpenBSD is not first class port and we are in code freeze.

the fact that OpenBSD 5.5 just released is irrelevant here.

[minux1, 2014-05-02 18:39:34]

On May 2, 2014 1:18 PM, "minux" <minux.ma@gmail.com> wrote:
> I think this should wait until 1.4.
> OpenBSD is not first class port and we are in code freeze.
i want to add that on issue 7919, the reporter confirmed that 1.3 all.bash
finished correctly on OpenBSD 5.5, so even one less reason to push this for
1.3.

[mikio, 2014-05-02 23:07:51]

Joel and Russ,

On Sat, May 3, 2014 at 1:18 AM, Russ Cox <rsc@golang.org> wrote:

> Was WALTSIG in the 1.2 release? If so, please keep it here.

I'm a bit confused. If I understand correctly, we agreed that;
- go1.3 supports openbsd 5.5 only because 5.5 includes breaking changes(*),
- the changeset 18816:5626eb9eda64(**) drops tons of constants that
not supported in 5.5,
- and current tip has a inconsistency btw amd64 and 386; a lack of
TIOCGSID for 386.

So, what's the right way to support openbsd in go1.3?

*) https://groups.google.com/d/msg/golang-dev/mcAKTGffTZA/SeqEiz4H4BsJ
**) https://code.google.com/p/go/source/detail?r=5626eb9eda64

PS: Joel, I'm guessing you have a plan to send a openbsd note for
doc/go1.3.html later, thanks. ;)

[mikio, 2014-05-03 00:16:59]

On Sat, May 3, 2014 at 8:07 AM, Mikio Hara <mikioh.mikioh@gmail.com> wrote:

> - and current tip has a inconsistency btw amd64 and 386; a lack of
> TIOCGSID for 386.

oops, hands slipped. this is a different issue. will send a separate cl.

> So, what's the right way to support openbsd in go1.3?

just read both opinions in other cl.

Joel: Obviously we could add a const for this, however WALTSIG support
no longer exists so keeping syscall.WALTSIG around seems fairly
pointless.

Russ: I don't think we should be removing names if we don't need to.
If you need to move WALTSIG into non-generated code that's fine.as a
matter of policy, we do not remove defined things. The API tool is
there to keep us honest, not to write exceptions for.

well, it's your call, Joel. because you are the maintainer of openbsd.
if you are happy with Russ's opinion, we probably need to restore the
dropped constants/syscalls during go1.3 cycle.

[mikio, 2014-05-05 04:40:22]

On Sat, May 3, 2014 at 9:16 AM, Mikio Hara <mikioh.mikioh@gmail.com> wrote:

> well, it's your call, Joel. because you are the maintainer of openbsd.
> if you are happy with Russ's opinion, we probably need to restore the
> dropped constants/syscalls during go1.3 cycle.

fyi: now this cl and 94950043 restore the dropped constants by
https://codereview.appspot.com/13368046.

[bradfitz, 2014-05-06 18:06:50]

LGTM



On Fri, May 2, 2014 at 7:46 AM, <mikioh.mikioh@gmail.com> wrote:

> Reviewers: rsc, jsing,
>
> Message:
> Hello rsc@golang.org, jsing@google.com (cc:
> golang-codereviews@googlegroups.com),
>
> I'd like you to review this change to
> https://code.google.com/p/go
>
>
> Description:
> syscall: regenerate z-files for openbsd 5.5
>
> Update issue 7049
>
> Please review this at https://codereview.appspot.com/96970043/
>
> Affected files (+1, -2 lines):
>   M src/pkg/syscall/zerrors_openbsd_386.go
>   M src/pkg/syscall/zerrors_openbsd_amd64.go
>
>
> Index: src/pkg/syscall/zerrors_openbsd_386.go
> ===================================================================
> --- a/src/pkg/syscall/zerrors_openbsd_386.go
> +++ b/src/pkg/syscall/zerrors_openbsd_386.go
> @@ -1228,6 +1228,7 @@
>         TIOCGETD                          = 0x4004741a
>         TIOCGFLAGS                        = 0x4004745d
>         TIOCGPGRP                         = 0x40047477
> +       TIOCGSID                          = 0x40047463
>         TIOCGTSTAMP                       = 0x400c745b
>         TIOCGWINSZ                        = 0x40087468
>         TIOCMBIC                          = 0x8004746b
> @@ -1296,7 +1297,6 @@
>         VSUSP                             = 0xa
>         VTIME                             = 0x11
>         VWERASE                           = 0x4
> -       WALTSIG                           = 0x4
>         WCONTINUED                        = 0x8
>         WCOREFLAG                         = 0x80
>         WNOHANG                           = 0x1
> Index: src/pkg/syscall/zerrors_openbsd_amd64.go
> ===================================================================
> --- a/src/pkg/syscall/zerrors_openbsd_amd64.go
> +++ b/src/pkg/syscall/zerrors_openbsd_amd64.go
> @@ -1296,7 +1296,6 @@
>         VSUSP                             = 0xa
>         VTIME                             = 0x11
>         VWERASE                           = 0x4
> -       WALTSIG                           = 0x4
>         WCONTINUED                        = 0x8
>         WCOREFLAG                         = 0x80
>         WNOHANG                           = 0x1
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[jsing, 2014-05-06 18:27:46]

I really do not understand the point of this - I get the Go API promise, however
the syscall package is somewhat special (and I vaguely recall there being
previous discussion around this) and even more so in this case (Go 1.3 will
simply not work on OpenBSD versions older than 5.5).

By providing these constants people are going to use them and potentially expect
things to work as they did previously - but they will not. At best they'll get
an error, at worst they will silently be ignored causing debugging difficulties.
IMO it is far better to remove them and require a code change.

Do we really want to provide invalid and non-functional syscall constants simply
so that we can maintain our Go API promise?

[iant, 2014-05-06 18:39:17]

The Go 1 promise is that programs written for Go 1.x will build and run for Go
1.y where y >= x.  This applies to the syscall package as it applies to all
other packages.  We should perhaps have relaxed the requirement on the syscall
package, but we didn't.

There is an exclusion for bugs.  If there is no way that the constant could have
been used in a working Go program in 1.2, then we can consider removing it.  If
a program would have worked in 1.2, but there is no way that it can work in 1.3,
then we can consider removing it.

But those requirements are intended to be hard to meet.  We should err on the
side of being conservative.

I have no idea about the specific details here.  Do you want to present the case
for removing constants present in 1.2?  From your message it appears that the
constants could be used correctly in 1.2.  Can you explain why it is not
possible to use them in 1.3?

[rsc, 2014-05-08 14:06:06]

LGTM

[klinikbatin.com, 2014-05-08 16:12:16]

first test

[mikio, 2014-05-10 00:00:30]

hi joel,

i think i need your lgtm to this cl.

On 2014/05/06 18:27:46, jsing wrote:

> Do we really want to provide invalid and non-functional syscall constants
simply
> so that we can maintain our Go API promise?

look like that's the landing point. fortunately the constants are just for, a)
linux
binary emulation operations and notifications/signals, b) removed ipv6 faith tcp
over ipv6/ipv4 relaying, and we can expect that such users have better working
knowledge to understand what they should do.

[mikio, 2014-05-10 00:15:18]

hi ian,

On 2014/05/06 18:39:17, iant wrote:

> I have no idea about the specific details here.  Do you want to present the
case
> for removing constants present in 1.2?  From your message it appears that the
> constants could be used correctly in 1.2.  Can you explain why it is not
> possible to use them in 1.3?

joei says: a) go1.3 only supports openbsd-5.5 (and beyond), b) generated stuff
w/ go1.3 never works on opnebsd-5.4 and above because the breaking changes
in 5.5 include critical reshuffling syscall numbers and abi tweaks.

it's not possible that any version of released go runs on openbsd-5.5, also
go1.3
runs on openbsd-5.4 and above.

[iant, 2014-05-10 00:35:38]

On 2014/05/10 00:15:18, mikio wrote:
> hi ian,
> 
> On 2014/05/06 18:39:17, iant wrote:
> 
> > I have no idea about the specific details here.  Do you want to present the
> case
> > for removing constants present in 1.2?  From your message it appears that
the
> > constants could be used correctly in 1.2.  Can you explain why it is not
> > possible to use them in 1.3?
> 
> joei says: a) go1.3 only supports openbsd-5.5 (and beyond), b) generated stuff
> w/ go1.3 never works on opnebsd-5.4 and above because the breaking changes
> in 5.5 include critical reshuffling syscall numbers and abi tweaks.
> 
> it's not possible that any version of released go runs on openbsd-5.5, also
> go1.3
> runs on openbsd-5.4 and above.

Thanks.  If I understand you correctly, this seems like an argument why these
constants are not necessary for Go 1.3.  But it doesn't seem like an argument
for taking constants that were present in Go 1.2 and removing them in Go 1.3.

All else being equal, I would prefer to keep constants that are present in Go
1.2 if possible.  That's what backward compatibility means; when possible, you
keep things the same.  I don't think we should remove the constants merely
because they are useless.  I think we need a stronger reason.

Ian

[mikio, 2014-05-10 01:08:20]

On Sat, May 10, 2014 at 9:35 AM,  <iant@golang.org> wrote:

> Thanks.  If I understand you correctly, this seems like an argument why
> these constants are not necessary for Go 1.3.  But it doesn't seem like
> an argument for taking constants that were present in Go 1.2 and
> removing them in Go 1.3.

thanks for the clarification. wait for joel.

[bradfitz, 2014-05-15 19:39:31]

Ping Joel / Mikio.

[mikio, 2014-05-15 21:23:05]

i'd wait for joel until next monday.

On Fri, May 16, 2014 at 4:39 AM,  <bradfitz@golang.org> wrote:
> Ping Joel / Mikio.
>
>
> https://codereview.appspot.com/96970043/
>
> --
> You received this message because you are subscribed to the Google Groups
> "golang-codereviews" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-codereviews+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[bradfitz, 2014-05-15 21:27:36]

LGTM

I'd just check it in now.  It seems fine, and we want to get things in
before the next 1.3 pre-release.

Joel can object later if he doesn't like it.



On Thu, May 15, 2014 at 2:23 PM, Mikio Hara <mikioh.mikioh@gmail.com> wrote:

> i'd wait for joel until next monday.
>
> On Fri, May 16, 2014 at 4:39 AM,  <bradfitz@golang.org> wrote:
> > Ping Joel / Mikio.
> >
> >
> > https://codereview.appspot.com/96970043/
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "golang-codereviews" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to golang-codereviews+unsubscribe@googlegroups.com.
> > For more options, visit https://groups.google.com/d/optout.
>

[mikio, 2014-05-15 21:30:54]

fine, will submit today. can you give a lgmt to cl 94950043 too?

[mikio, 2014-05-15 21:49:26]

*** Submitted as https://code.google.com/p/go/source/detail?r=1fdd9c6c03c9 ***

syscall: regenerate z-files for openbsd

This CL restores dropped constants not supported in OpenBSD 5.5
and tris to keep the promise of API compatibility.

Update issue 7049

LGTM=jsing, bradfitz, rsc
R=rsc, jsing, robert.hencke, minux.ma, bradfitz, iant
CC=golang-codereviews
https://codereview.appspot.com/96970043

[gobot, 2014-05-15 22:13:58]

This CL appears to have broken the freebsd-386 builder.
See http://build.golang.org/log/0bdadbe7a59cdf815b5fd3ae9d1926d7acc0319f