> >>> +int dprc_get_container_id(struct fsl_mc_io *mc_io, int *container_id) > >> > >> This one is definitely a misnomer. It's a command that operates on the > >> MC object, not a DPRC object. Also it doesn't fetch a random > >> "container_id", it fetches the root container id. > > > > It's not strictly the root container. It fetches the container/DPRC ID > > associated with the portal you are using. A virtual machine would use > > it to fetch it's container ID. > > So does every portal properly react to this call?
Yes, they should. > Or do only container > portals react to it? Every portal is associated with some contianer-- either built into the container/DPRC object, or in a container/DPRC. > In fact, what does make the initial portal special? Nothing...it has the same semantics as any other portal. > Who reacts to > DPMNG_CMDID_foo calls? Every DPRC or only the initial root? All portals. It just means 'what container am I in?' > >> Please move it and its definition to the files that operate on the MC > >> management interface. > > > > Note, the binary interface opcode really is DPRC_CMDID_GET_CONT_ID. > > > > We can request that the binary interface naming be changed, but wouldn't > > it be better to keep the functions separated by opcode type-- having > > DPRC_CMDID* opcode-based commands be in one file and DPMNG_CMDID* commands > > in a separate file? > > It really depends on what the semantics are. If this is a call that's > only valid on the MC root, then it should belong there. If it's > available on every container portal, it should be part of dprc of course. It is valid on any portal, including container portals. For that reason, I do think it may make sense for it to be a DPMNG* command. But, I would say leave the files implementing the opcode groupings alone until the MC architecture is changed. Stuart -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/