I get that this whole function is about duplicating what runc does here https://github.com/opencontainers/runc/blob/master/ps.go#L41-L95, but I think we should add an added value, that is gather all those data inside a structure dedicated to this. This structure would be then marshalled so that it would become a JSON byte array that we can send to the runtime(virtcontainers basically).

do you mean to put all output inside a struct?

type psOutput struct {
    output byte[]
}

I wonder if this is really needed

@devimc no, I meant having something nicer than only an array of byte already in the expected format. Basically, I was thinking that the agent could parse the output of the ps command to put it into a structure like:

type processInfo struct {
        Name string
        PID     string
        ...
}

type processListInfo []processInfo

And this would be marshalled into a json byte array through the response. Then we would have virtcontainers relying on this specific structure to unmarshal the byte array. And then, this structure would be passed back to the runtime. The runtime wrapper being the only one doing the formatting.

I am saying all of this because if we think about virtcontainers as a generic library, we want to return a process list as a standardized structure that any consumer of virtcontainers could format the way it wants.

@sboeuf the problem with the structure that you propose is that we don't know the options user will provide

That's why we need to have every potential output covered by this structure. The output will depend on the options, I agree, but eventually we would be sending the same structure.

@devimc I'd agree with @sboeuf here. The agent should send data without assuming anything about the end user expected format. The runtime should be the one doing the formatting/filtering, not the agent.

@sameo great! , so can we merge?

@devimc I don't think you're marshalling an actual structure that the runtime/virtcontainers could unmarshal and format filter, right ?

runc doesn't format/filter the output because docker does that [1], I consider we should have a similar implementation and leave to docker decide the output format.

[1] - https://github.com/moby/moby/blob/402540708c9a0c35dc0b279a0f330455633537b8/daemon/top_unix.go#L63

All right, let's get this one in.

Because it has to return a reply, it should be part of a different map. Create a new one called callbackWithReplyList

This check should not return an error anymore. Indeed, relying on what I have mentioned above, if we add this new Hyper command to a new map called callbackWithReplyList, we should not fail but instead, we should try this other list. If we cannot find for both lists, then we can really fail this time.
This would allow not to force all the other commands to return nil all the time because they have no byte to send back.