I just did a global s/vps/container/ and it looks pretty reasonable, atCan be ommited.
least from my point of view.
Couple of minor naming nitpick questions, though. Is vps/container_info
really what we want to call it? It seems to me to be the basis for a
real "container", without the _info part.
"tsk->owner_container" That makes it sound like a pointer to the "taskThis is why I don't like "container" name.
owner's container". How about "owning_container"? The "container
owning this task". Or, maybe just "container"?
Any particular reason for the "u32 id" in the vps_info struct as opposedVPS ID is passed to/from user space APIs and when you have a cluster with different archs and VPSs it is better to have something in common for managing this.
to one of the more generic types? Do we want to abstract this one in
the same way we do pid_t?
The "host" in "host_container_info" doesn't mean much to me. Though, Iinit_container?
guess it has some context in the UML space. Would "init_container_info"
or "root_container_info" be more descriptive?
Lastly, is this a place for krefs? I don't see a real need for aI don't see much need for krefs, do you?
destructor yet, but the idea is fresh in my mind.
How does the attached patch look?I will resend all 5 patches tomorrow. And maybe more.