add support for FreeBSD 10

[Mikio Hara]

Hi,

FreeBSD 10 has a few API/ABI breaks(*) we need to handle appropriately
for adding support for FreeBSD 10 to Go 1.3. So I propose that;

1) update current (FreeBSD 8/9-based) syscall z-files to 10-based
instead of having chimerical 8/9/10-based z-files

2) apply few patches to the package syscall, os and archive/tar to
ensure Go 1.3 standard library and sub repository stuff work well on
8/9-STABLE
- an experiment to test Go 1.3 on 8/9/10-STABLE works well, see issue 7193

Not sure what will happen in the next major release FreeBSD 11, but
freebsd guys usually work carefully to keep backwards compatibility
and give developers a few years transition period when an ABI break
happens. I don't think this kind of traversal happens so frequently.

Thoughts?

*)
r205792: Rename st_*timespec fields to st_*tim for POSIX 2008 compliance.
- http://svnweb.freebsd.org/base?view=revision&revision=205792
- from 9.0.0R

r254804: Restructure the mbuf pkthdr to make it fit for upcoming
capabilities and features.
- http://svnweb.freebsd.org/base?view=revision&revision=254804
- from 10.0.0R

r255219: Change the cap_rights_t type from uint64_t to a structure
that we can extend in the future in a backward compatible (API and
ABI) way.
- http://svnweb.freebsd.org/base?view=revision&revision=255219
- from 10.0.0R

[Brad Fitzpatrick]

I've read this email a few times and I don't understand the implications.

You propose changing things but it's not clear if we have to (now or eventually?), or what breaks if we do.

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Mikio Hara]

Sorry for being late.

On Thu, Jan 30, 2014 at 6:31 PM, Brad Fitzpatrick <brad...@golang.org> wrote:

> I've read this email a few times and I don't understand the implications.

Sure, sorry about that. Please see attached which shows the
syscall/ABI difference btw kernel versions. I've checked border
versions/architectures last weeks and confirmed that the difference
btw architectures does affect nothing. We can simply handle
freebsd/amd64,386,arm in one way.

> You propose changing things but it's not clear if we have to (now or
> eventually?), or what breaks if we do.

I'd like to propose that, a1) regenerating z-files on FreeBSD 10 as
syscall API breaking changes, but preserves other package API, a2)
introducing a few kernel version sensitive code to the package syscall
and os to fill that gap btw kernel versions. In this plan, the
breaking changes will be:
- Syscall structure: Stat_t and IfData,
- Syscall number: SYS_CAP_XXX, Capsicum related numbers,
- Syscall constants: IfData related constants.
See https://codereview.appspot.com/57210043/ for the details.

Other options would be, b) keeping syscall API and introducing more
crafty version checking/sensitive code to everyplace, but I'm not keen
on this because maintaining such fragile code with hand-edited z-files
would be pretty tough, c) or deciding not to support freebsd 10
including freebsd/arm in Go 1.3.

Thoughts?

P.S.
CLs for plan (a1) and (a2) are the following:
syscall: regenerate z-files on FreeBSD 10,
https://codereview.appspot.com/56770044/
os: add support for FreeBSD 10, https://codereview.appspot.com/56920043/
archive/tar: add support for FreeBSD 10,
https://codereview.appspot.com/56930043/
net, syscall: add support for FreeBSD 10,
https://codereview.appspot.com/56980043/
os: handle file creation with close-on-exec correctly on darwin,
freebsd, https://codereview.appspot.com/64510043/
api: add FreeBSD 10 exceptions, https://codereview.appspot.com/57210043/

[Russ Cox]

Is it just Stat_t and IfData that changed? Can we write the functions that use those to rewrite the struct to the appropriate version for the underlying kernel? We did this for some other struct on Linux if I remember correctly. The idea is that you'd leave Stat_t alone and make syscall.Stat check the kernel version and if needed, pass in a stat10_t and then copy the fields back into the original Stat_t, all transparently.

[Mikio Hara]

On Thu, Feb 27, 2014 at 3:40 AM, Russ Cox <r...@golang.org> wrote:

> Is it just Stat_t and IfData that changed?

From the API compatibility checker point of view, yes... actually no.
syscall.Stat_t doesn't matter because of field name changes only.
syscall.IfData is a problem. It is embedded into some structures such
as syscall.IfMsghdr and syscall.InterfaceMessage struct wraps it and
implements syscall.RoutingMessage interface which is part of
syscall.ParseRoutingMessage and syscall.ParseRoutingSockaddr API.

Another problem would be to support for freebsd/arm. At the moment tip
contains broken, non-EABI syscall structures and constants and we need
to update them as freebsd 10 port. I'm not keen on having a situation
like syscall.IfData for amd64/386 is based on FreeBSD 8 and for arm is
based on syscall.FreeBSD 10.

[minux]

On Wed, Feb 26, 2014 at 8:33 PM, Mikio Hara <mikioh...@gmail.com> wrote:

On Thu, Feb 27, 2014 at 3:40 AM, Russ Cox <r...@golang.org> wrote:
> Is it just Stat_t and IfData that changed?

From the API compatibility checker point of view, yes... actually no.
syscall.Stat_t doesn't matter because of field name changes only.

Let's stick with the older names. I don't think we should break the user's

code just to conform to latest system naming.

As for the Caps, I regret we add them that early. In general, we should

avoid adding any non-finalized interface to syscall package in the future.

syscall.IfData is a problem. It is embedded into some structures such
as syscall.IfMsghdr and syscall.InterfaceMessage struct wraps it and
implements syscall.RoutingMessage interface which is part of
syscall.ParseRoutingMessage and syscall.ParseRoutingSockaddr API.

Modifying them essentially drops support for earlier FreeBSD versions,

I don't think we want to do that. We should workaround the change.

(This is unlike the OpenBSD 64-bit transition where workaround is impossible

or extremely cumbersome.) 

> Can we write the functions that
> use those to rewrite the struct to the appropriate version for the
> underlying kernel? We did this for some other struct on Linux if I remember
> correctly. The idea is that you'd leave Stat_t alone and make syscall.Stat
> check the kernel version and if needed, pass in a stat10_t and then copy the
> fields back into the original Stat_t, all transparently.

Another problem would be to support for freebsd/arm. At the moment tip
contains broken, non-EABI syscall structures and constants and we need
to update them as freebsd 10 port. I'm not keen on having a situation
like syscall.IfData for amd64/386 is based on FreeBSD 8 and for arm is
based on syscall.FreeBSD 10.

I don't think that's problem. ARM support is added for FreeBSD 10, and x86

support is added much earlier. (This is documented on the install page.)

[Mikio Hara]

On Thu, Feb 27, 2014 at 10:46 AM, minux <minu...@gmail.com> wrote:

>> Another problem would be to support for freebsd/arm. At the moment tip
>> contains broken, non-EABI syscall structures and constants and we need
>> to update them as freebsd 10 port. I'm not keen on having a situation
>> like syscall.IfData for amd64/386 is based on FreeBSD 8 and for arm is
>> based on syscall.FreeBSD 10.
>
> I don't think that's problem. ARM support is added for FreeBSD 10, and x86
> support is added much earlier. (This is documented on the install page.)

Which do you think is better?
a) z-files for freebsd/arm contain pure freebsd10-based stuff and
different from freebsd/amd64,386,
b) or crafted stuff, perhaps some constants are not good for freebsd10/arm.

Hm, seems like a compromise would be:

For syscall structures, we will keep old stuff as much as possible. In
this case changes to the both structures are namespace and field size
(32-bit to 64-bit, fortunately they don't use upper 32-bit yet)
tweaks, so we can keep FreeBSD 8-based stat and if_data structures. A
downside would be... they don't work for subrepo or external stuff on
FreeBSD 10, but it doesn't matter... right?

For syscall numbers, well, I'd update to FreeBSD 10-based because
adding SYS_ACCEPT4 on FreeBSD 10 is one of the motivations to me. What
do you think?

For syscall constants, almost the same as structures.

Does this make sense?

[Mikio Hara]

On Thu, Feb 27, 2014 at 12:43 PM, Mikio Hara <mikioh...@gmail.com> wrote:

> For syscall constants, almost the same as structures.

correction: ... almost the same as structures except O_CLOEXEC, this
is another motivation.

[minux]

On Wed, Feb 26, 2014 at 10:43 PM, Mikio Hara <mikioh...@gmail.com> wrote:

On Thu, Feb 27, 2014 at 10:46 AM, minux <minu...@gmail.com> wrote:

>> Another problem would be to support for freebsd/arm. At the moment tip
>> contains broken, non-EABI syscall structures and constants and we need
>> to update them as freebsd 10 port. I'm not keen on having a situation
>> like syscall.IfData for amd64/386 is based on FreeBSD 8 and for arm is
>> based on syscall.FreeBSD 10.
>
> I don't think that's problem. ARM support is added for FreeBSD 10, and x86
> support is added much earlier. (This is documented on the install page.)

Which do you think is better?
a) z-files for freebsd/arm contain pure freebsd10-based stuff and
different from freebsd/amd64,386,
b) or crafted stuff, perhaps some constants are not good for freebsd10/arm.

Hm, seems like a compromise would be:

For syscall structures, we will keep old stuff as much as possible. In
this case changes to the both structures are namespace and field size
(32-bit to 64-bit, fortunately they don't use upper 32-bit yet)
tweaks, so we can keep FreeBSD 8-based stat and if_data structures. A
downside would be... they don't work for subrepo or external stuff on
FreeBSD 10, but it doesn't matter... right?

I think we can do the translation dynamically as what Russ said, and also

added a IfData10 for example for the correct structure in case anyone needs that.

(There once was a similar structure definition problem for Windows right after Go 1.0,

and that's before api/except.txt is introduced. At that time we used exactly what

Russ said. I kinda think after the introduction of api/except.txt, we are using too

much of it.)

For the stat_t renaming, I think we can just keep that. We don't need to keep renaming

with each kernel release, as that will break otherwise perfectly fine user code, which

is precisely what we do not like to see.

For syscall numbers, well, I'd update to FreeBSD 10-based because
adding SYS_ACCEPT4 on FreeBSD 10 is one of the motivations to me. What
do you think?

Is it just an addition or a change? If it's an addition, fine. If it's change in syscall numbers,

then we probably need to discuss the best way to do for the specific case. 

For syscall constants, almost the same as structures.

Does this make sense?

Yes. I think for the syscall package, the goal is not to follow exactly the OS definition

(we probably should think about this issue more in Go 2. For example, one way will be

to add more portable functions, reduce the need for syscall, and exempt it from the API

contract), but keep existing code compilable.

[Mikio Hara]

On Thu, Feb 27, 2014 at 5:08 PM, minux <minu...@gmail.com> wrote:

>> For syscall numbers, well, I'd update to FreeBSD 10-based because
>> adding SYS_ACCEPT4 on FreeBSD 10 is one of the motivations to me. What
>> do you think?
>
> Is it just an addition or a change? If it's an addition, fine. If it's
> change in syscall numbers,
> then we probably need to discuss the best way to do for the specific case.

SYS_ACCEPT4 is just introduced in FreeBSD 10. What about numbers for
Capsicum? Should we keep experimental ones?

Then, with your comments I'll re-wrap CLs (tonight).

[minux]

It's late in the Go 1.3 cycle, let's just add what we need. I even think we shouldn't

regenerate the z* files, just manually add what we really want to commit to.

(It seems the Capsicum interface already changes once, so we can't be sure it

won't change again. To reduce headaches for 1.4, let's leave it out for 1.3.)

Then, with your comments I'll re-wrap CLs (tonight).

Thank you!

[Mikio Hara]

Looks like all set to land (except a few bugs on freebsd/386,
runtime/cgo on freebsd/arm). Will submit soon.

[Russ Cox]

What happened here?

It looks like the original proposal was that we drop support for FreeBSD < 10, but then we backed down to doing something that would work on 10 but also keep working on older systems.

What is the minimum required FreeBSD version for Go, for each architecture? Is this different than in Go 1.2? Are there different minimums for using certain fringe functionality (like enumerating network interfaces)?

Thanks.

Russ

[Rob Pike]

Please explain concisely for those not skilled in the art. I need to
write explanatory text for the 1.3 release notes that say what the
state is for Go on FreeBSD in this release.

-rob

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.

> For more options, visit https://groups.google.com/d/optout.

[Pavel Zholkover]

8.3 (about to be EOLed on April 30th) is the minimum version which will work with the real O_CLOEXEC (!= 0) introduced in a3b2bc0b515e.
The SIOCAIFADDR, SIOCSIFPHYADDR ioctl's (for interface aliasing and tunneling) mentioned in the coderevew were not actually modified. They depend on sizeof(struct ifaliasreq):
struct ifaliasreq {
        char    ifra_name[IFNAMSIZ];            /* if name, e.g. "en0" */
        struct  sockaddr ifra_addr;
        struct  sockaddr ifra_broadaddr;
        struct  sockaddr ifra_mask;
};
which is pretty "stable".
I could setup a builder for 8.4 on an old Thinkpad T61 if there's interest.

[Mikio Hara]

sorry for being late, confrimed off-list gentle ping too. i'm now getting back to online slowly but will send a note tonight (or tomorrow morning).

 

 

[Mikio Hara]

On Wed, Apr 16, 2014 at 5:26 AM, Russ Cox <r...@golang.org> wrote:

> It looks like the original proposal was that we drop support for FreeBSD <
> 10, but then we backed down to doing something that would work on 10 but
> also keep working on older systems.

Ah, I thought that my original proposal meant just adding support for
FreeBSD 10. It just asked how to fill the gap between versions (I
preferred changing a few exposed structures/constants in syscall
package) and got feedback like "let's keep old version stuff as much
as possible".

> What is the minimum required FreeBSD version for Go, for each architecture?
> Is this different than in Go 1.2? Are there different minimums for using
> certain fringe functionality (like enumerating network interfaces)?

Required versions must be:
freebsd/amd64: from 8.0 through 10.0 (or any version from 8-STABLE
through 10-STABLE), probably it works well on 11-CURRENT but not
tested,
freebsd/386: ditto,
freebsd/arm: 10.0 (or any version from 10-STABLE), probably it works
well on 11-CURRENT but not tested.

It's almost the same as Go 1.2 except freebsd/arm. I guess go1.2
doesn't work perfectly on freebsd10/arm because of the lack of
ARM-EABI patches and syscall argument gaps between freebsd10 and prior
to 10.

Hope this helps.


---
Note:

* Basic support for freebsd10/arm
- in go1.2 cycle minux decided to support only arm-eabi versions so
the rest work is just adapting runtime/syscall packages for arm-eabi;
regenerating eabi conformed go structures using godefs and fixing
broken arm assembly fragments
- also minux enables cgo on freebsd10/arm

* Basic support for freebsd10/{amd64,386,arm}
- there's no plan to introduce a cross compile feature for multiple os
versions to build tools so just reuse existing syscall structures and
constants with a internal plumbing work; checking the running kernel
version and filling the gap between versions in syscall package
- as a consequence, a few syscall structures and constants are
incompatible with 10.0 and beyond:
-- constants: SIOCAIFADDR, SIOCSIFPHYADDR (not used in standard library)
-- syscall numbers: SYS_CAP_NEW,SYS_CAP_GETRIGHTS,
SYS_CAP_ENTER,SYS_CAP_GETMODE (not used in standard library)
-- constants: SizeofIfData, SizeofIfMsghdr
-- structures: IfData, IfMsghdr
- other non-conflicted structures and constants are updated

* Additional support for freebsd{8.3-,9,10}/{amd64,386} and freebsd10/arm
- 10.0 (or 10-stable) allows to use the close-on-exec socket creation
feature so enables it in net package
- 8.3 and beyond allow to use the close-on-exec file creation feature
so enables it in os package

[Mikio Hara]

Hi Pavel,

On Sat, Apr 19, 2014 at 7:18 AM, Pavel Zholkover <paul...@gmail.com> wrote:

> The SIOCAIFADDR, SIOCSIFPHYADDR ioctl's (for interface aliasing and
> tunneling) mentioned in the coderevew were not actually modified. They
> depend on sizeof(struct ifaliasreq):
> struct ifaliasreq {
> char ifra_name[IFNAMSIZ]; /* if name, e.g. "en0" */
> struct sockaddr ifra_addr;
> struct sockaddr ifra_broadaddr;
> struct sockaddr ifra_mask;
> };
> which is pretty "stable".

http://svnweb.freebsd.org/base/release/10.0.0/sys/net/if.h?revision=260789&view=markup#l413

Please be informed that go1.3 would include pre-10.x compatible
syscall.SIOCAIFADDR and syscall.SIOCSIFPHYADDR constants,
incompatible with 10.x and beyond. So if you want to support both 10
and prior to 10 kernels, please keep own SIOCAIFADDR, SIOCSIFPHYADDR
constants and ifaliasreq structure for both versions.

[minux]

On Wed, Apr 23, 2014 at 12:30 AM, Mikio Hara <mikioh...@gmail.com> wrote:

On Wed, Apr 16, 2014 at 5:26 AM, Russ Cox <r...@golang.org> wrote:

> It looks like the original proposal was that we drop support for FreeBSD <
> 10, but then we backed down to doing something that would work on 10 but
> also keep working on older systems.

Ah, I thought that my original proposal meant just adding support for
FreeBSD 10. It just asked how to fill the gap between versions (I
preferred changing a few exposed structures/constants in syscall
package) and got feedback like "let's keep old version stuff as much
as possible".

> What is the minimum required FreeBSD version for Go, for each architecture?
> Is this different than in Go 1.2? Are there different minimums for using
> certain fringe functionality (like enumerating network interfaces)?

Required versions must be:
freebsd/amd64: from 8.0 through 10.0 (or any version from 8-STABLE
through 10-STABLE), probably it works well on 11-CURRENT but not
tested,
freebsd/386: ditto,
freebsd/arm: 10.0 (or any version from 10-STABLE), probably it works
well on 11-CURRENT but not tested.

there is one net package test failure in TestInterface, basically all returned

interface names are empty. I thought it was because we don't really support

11 yet. But now that I've read your report, and verified that -current does

pass all.bash at least on amd64, so the test failure should be fixed on arm.

However, all.bash passes on freebsd10/arm, so I'm not sure why the net

test fail on -current yet..

It's almost the same as Go 1.2 except freebsd/arm. I guess go1.2
doesn't work perfectly on freebsd10/arm because of the lack of
ARM-EABI patches and syscall argument gaps between freebsd10 and prior
to 10.

---
Note:

* Basic support for freebsd10/arm
- in go1.2 cycle minux decided to support only arm-eabi versions so
the rest work is just adapting runtime/syscall packages for arm-eabi;
regenerating eabi conformed go structures using godefs and fixing
broken arm assembly fragments

yeah, prior to FreeBSD 10, the ARM support was preliminary at best.

Also supporting both OABI and EABI is basically not maintainable (yes,

I've learnt the mistake from the Linux OABI testing [Issue 5685]).

Also about 2.5 weeks ago, -current enabled stable multi-core support for

ARM, so FreeBSD has become a series OS on ARM.

[Pavel Zholkover]

Thanks, I didn't notice that one but it raises the following issue.
Anyone using SIOCAIFADDR from go1.3 and bellow on FreeBSD 10 will essentially be getting the compat syscall
/usr/include/sys/sockio.h:/OSIOCAIFADDR/
#define    OSIOCAIFADDR     _IOW('i', 26, struct oifaliasreq)/* add/chg IF alias */

/usr/src/sys/netinet/in.c:/^in_control/
        /*
         * Pre-10.x compat: OSIOCAIFADDR passes a shorter
         * struct in_aliasreq, without ifra_vhid.
         */
        if (cmd == OSIOCAIFADDR)
                cmd = SIOCAIFADDR;

Which is fine IMHO, but there is no such special casing for SIOCSIFPHYADDR in the kernel, so there's no ioctl 0x80406946 (the new one is 0x80446946).

[Mikio Hara]

On Thu, Apr 24, 2014 at 6:05 AM, Pavel Zholkover <paul...@gmail.com> wrote:

> Which is fine IMHO, but there is no such special casing for SIOCSIFPHYADDR
> in the kernel, so there's no ioctl 0x80406946 (the new one is 0x80446946).

you can keep your own syscall_freebsd.go which contains:

const sysOldSetInterfacePhysAddr 0x80406946
const sysSetInterfacePhysAddr 0x80446946
type sysOldInterfaceAliasReq { ... }
type sysInterfaceAliasReq { ... }

then, adds a few lines.

osrel, err := syscall.SysctlUint32("kern.osreldate")
if err != nil {
return
}
// See http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html.
if osrel > 1000000 {
// pass sysSetInterfacePhysAddr and sysInterfaceAliasReq to
syscall.Syscall
} else {
// pass sysOldSetInterfacePhysAddr and sysOldInterfaceAliasReq
to syscall.Syscall
}

[Mikio Hara]

On Wed, Apr 23, 2014 at 2:30 PM, minux <minu...@gmail.com> wrote:

>> freebsd/arm: 10.0 (or any version from 10-STABLE), probably it works
>> well on 11-CURRENT but not tested.
>
> there is one net package test failure in TestInterface, basically all
> returned
> interface names are empty. I thought it was because we don't really support
> 11 yet. But now that I've read your report, and verified that -current does
> pass all.bash at least on amd64, so the test failure should be fixed on arm.
>
> However, all.bash passes on freebsd10/arm, so I'm not sure why the net
> test fail on -current yet..

funny, perhaps it's a side effect of multicast and sockaddr_dl
cleanups on 11-current.

[Pavel Zholkover]

That makes sense, thanks!
Any thoughts on adding something like ioctl_bsd.go, ioctl_linux.go to the syscall package, so ioctls could be defined similarly to their C versions instead of numeric values:

var ioctl_TIOCGPTN = _IOR('T', 0x30, unsafe.Sizeof(_C_uint(0))) /* Get Pty Number (of pty-mux device) */