Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

proposal: x/net/route, vendor/golang.org/x/net/route: new package #14724

Closed
mikioh opened this issue Mar 9, 2016 · 13 comments
Closed

proposal: x/net/route, vendor/golang.org/x/net/route: new package #14724

mikioh opened this issue Mar 9, 2016 · 13 comments
Labels
FrozenDueToAge Proposal
Milestone
Go1.7

Comments

@mikioh
Copy link
Contributor

mikioh commented Mar 9, 2016

Unlink Linux, BSD variants may change their kernel ABIs between major releases as reported in #7849. To follow the circumstances with minimal maintenance cost, I'd like to propose having an internal package that provides routing message/socket parsers.

Exposed APIs:

  • ABI agnostic routing message/socket types
  • Routing message/socket parsers
  • Destination address prefix lookup for helping address selection in net.Dialer

It's also fine vendoring "internal/x/golang.org/x/net/internal/route " if possible.
@mikioh mikioh added this to the Go1.7 milestone Mar 9, 2016
@mikioh mikioh added the Proposal label Mar 9, 2016
@adg
Copy link
Contributor

adg commented Mar 9, 2016

It's also fine vendoring "internal/x/golang.org/x/net/internal/route " if possible.

Do you mean that the existing route package provides this functionality? Are you proposing either vendoring that package, or alternately copying it over?

@mikioh
Copy link
Contributor Author

mikioh commented Mar 9, 2016

There's no route package yet. At this moment some (reusable) code fragments exist in syscall package. I'm sure I don't understand the difference between vendoring and duplication. It's just a thought that placing code on golang.org/x/net repository instead of standard library might be helpful for people who want to maintain each operating system's package/port collections. Do you have any suggestion on how to make a open-closed package, which is open for dependency management and closed for dependency hell.

@adg
Copy link
Contributor

adg commented Mar 9, 2016

Oh, well if there's a route package in x/net with the aim of re-use then it shouldn't be an internal package. That threw me.

Do you have any suggestion on how to make a open-closed package, which is open for dependency management and closed for dependency hell.

Can you be more specific?

@mikioh
Copy link
Contributor Author

mikioh commented Mar 9, 2016

Sure, two questions. Which is the preferable repository for the new package, standard or x/net? If the latter, what would be the maintenance policy of the branches on x/net? Is that the same as standard repository? (Looks like so, x/tools and x/net have release-branch.go1.x branches)

@adg
Copy link
Contributor

adg commented Mar 10, 2016

Which is the preferable repository for the new package, standard or x/net?

Is it for general use? Then x/net with the potential to promote it to the standard library at a later stage.

what would be the maintenance policy of the branches on x/net?

Packages in the sub-repositories are expected to be relatively stable unless marked otherwise, but they do not fall under the Go 1 compatibility promise. Heavily under-development or speculative packages sometimes live in the x/exp repo or exp directories inside a repo.

The x/tools and x/net repository both have release branch tags because parts of them are bundled in each binary release. We don't expect people to check out or work on those branches.

So I guess the question is: who is the package for?

@mikioh
Copy link
Contributor Author

mikioh commented Mar 10, 2016

So I guess the question is: who is the package for?

The primary customer is the net package of standard library. Others would be external packages that need to read routing information from BSD kernels without worrying about the gaps between platforms, kernel versions. I think that placing the code at golang.org/x/net/route and having a duplicate at src/internal/golang.org/x/net/route like x/net/http2/hpack makes sense. What do you think?

@adg
Copy link
Contributor

adg commented Mar 10, 2016

Yeah, I think it makes sense to put it in x/net to start with.

What are the immediate and ultimate impacts on the net package in the standard library? Reduced maintenance burden?

@mikioh
Copy link
Contributor Author

mikioh commented Mar 10, 2016

Yes, reducing maintenance cost is the main benefit. Additional benefit would be subtle until standard library provides QUIC-like super all-in-one userland transport protocol.

@mikioh mikioh changed the title proposal: net/internal/route: new package proposal: x/net/route, internal/golang.org/x/net/route: new package Mar 11, 2016
@bradfitz
Copy link
Contributor

This seems fine. I approve.

@gopherbot
Copy link

CL https://golang.org/cl/22446 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/22451 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/22450 mentions this issue.

@gopherbot
Copy link

CL https://golang.org/cl/22452 mentions this issue.

@mikioh mikioh changed the title proposal: x/net/route, internal/golang.org/x/net/route: new package proposal: x/net/route, vendor/golang.org/x/net/route: new package Apr 26, 2016
@mikioh mikioh removed their assignment May 6, 2016
gopherbot pushed a commit to golang/net that referenced this issue May 14, 2016
@cixtor
route: new package
30be488 
This change introduces a package that provides the basic manipulation of
routing facilities on BSD variants.

Unlike the existing APIs in syscall package of standard library, the
package tries to provide operating system and its architecture agnostic
APIs. At present, the package supports any version of Darwin, any
version of DragonFly BSD, FreeBSD 7 through 11, NetBSD 6 and above, and
OpenBSD 5.6 and above.

Updates golang/go#14724.

Change-Id: Id964ea22dec491ddac3776e3a8c8c10f140f96ac
Reviewed-on: https://go-review.googlesource.com/22446
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
gopherbot pushed a commit that referenced this issue May 14, 2016
@cixtor
vendor: import golang.org/x/net/route
aba7b3e 
golang.org/x/net/route becomes vendor/golang.org/x/net/route.

At git rev 30be488 (golang.org/cl/22446)

Updates #14724.

Change-Id: I41cfb5443aeecac4c71e843c09eb8c1d4b7413ea
Reviewed-on: https://go-review.googlesource.com/22450
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
gopherbot pushed a commit that referenced this issue May 15, 2016
@cixtor
syscall: deprecate routing message APIs for BSD variants
6d66819 
Also removes unnecessary test cases for avoiding unexpected failures on
newer operating systems.

Updates #14724.

Change-Id: I2291585d951fb70383da68293a6ac1ff3524c7f7
Reviewed-on: https://go-review.googlesource.com/22452
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@golang golang locked and limited conversation to collaborators May 15, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge Proposal
Projects
None yet
Milestone
Go1.7
Development

No branches or pull requests
4 participants
@bradfitz @mikioh @adg @gopherbot