refactor: move some c code to go #4309
Conversation
lifubang
force-pushed
the
refactor-c-to-go
branch
4 times, most recently
from
bbab957
to
c534efe
Compare
lifubang
force-pushed
the
refactor-c-to-go
branch
from
c534efe
to
62b3c18
Compare
lifubang
force-pushed
the
refactor-c-to-go
branch
2 times, most recently
from
169a838
to
eac3328
Compare
libcontainer/process_linux.go
Outdated
| @@ -76,6 +79,10 @@ func newProcessComm() (*processComm, error) { | |||
| if err != nil { | |||
| return nil, fmt.Errorf("unable to create init pipe: %w", err) | |||
| } | |||
| comm.stage1SockParent, comm.stage1SockChild, err = utils.NewSockPair("stage1") | |||
| if err != nil { | |||
| return nil, fmt.Errorf("unable to create init pipe: %w", err) | |||
There was a problem hiding this comment.
Although it's stage-1, do we need another name instead of init pipe for this log?
There was a problem hiding this comment.
fixed! Thanks. Welcome more reviews!
|
Needs rebase |
|
Maybe this should be postponed to v1.3, to avoid having regression in v1.2? |
libcontainer/configs/config.go
Outdated
| @@ -27,6 +27,11 @@ type IDMap struct { | |||
| Size int64 `json:"size"` | |||
| } | |||
|
|
|||
| // ToString is to serize the IDMap to a string. | |||
There was a problem hiding this comment.
Thanks, fixed.
Welcome more reviews!
Introduce a common parent struct `containerProcess`, let both `initProcess` and `setnsProcess` are inherited from it. Signed-off-by: lfbzhm <lifubang@acmcoder.com>
lifubang
force-pushed
the
refactor-c-to-go
branch
from
eac3328
to
6072f83
Compare
Move all the stage-1 c code and some of the stage-2 c code to go code, because they are not related to namespaces, they should be implemented by golang. Signed-off-by: lifubang <lifubang@acmcoder.com>
lifubang
force-pushed
the
refactor-c-to-go
branch
from
6072f83
to
b70c4af
Compare
Done. I'll do rebase again once #4312 merged. |
|
@lifubang I like the idea of the PR, but I'd prefer to merge this just after the 1.2.0 final release. I'd like to focus on bug-fixing now, to do the final release. This is non-trivial at all and has several semantic changes, there might be follow-up PRs to fix edge cases, and I really prefer to not put all of that on the hot-path to release 1.2.0. I think doing a 1.3.0 release in a few months after 1.2.0 is completely fine (indeed it was the original plan for 1.2, to be a few months after 1.1), if we have this PR (and probably we will have a few of the others that are around too), this makes sense to me as a new release. What do you think? |
Agree. |
|
I'll focus on this after the 1.2 release. Thanks for working on this! :) |
As mentioned in #3951 , we want to move c code to golang, there are many hard works to do.
This PR has done the first step, move all the stage-1 c code and some of the stage-2 c code to go code, because they are not related to namespaces, they should be implemented by golang.
This refactor brings one benifit, it reduces one process clone when start/run/create a container. But because the stage-1 c code is hard to move to go code, so it brings a Complexity for libct/nsenter, for example, it's hard to write unit tests for nsenter.
Welcome more suggestions.