[lkml]   [2006]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: (pspace,pid) vs true pid virtualization
Quoting Hubertus Franke (
> >>- Should a process have some sort of global (on the machine identifier)?
> First establish whether that global ID has to be persistent ...
> I don't see why ! In which case the TASK_REF is the perfect global ID.

The task_refs were only intended to be used in the kernel, iiuc.


> >>- Should we be able to have processes enter a pid space?
> >
> >
> >IMO that is crucial.
> Existing ones .. now that is potentially difficult to do. Particular
> if you want to enter a pidspace that has already been migrated.
> Because ones assigned pid might already been taken in the target pspace.

Well the answer changes depending on whether the question asks
about pid spaces, or full containers. For full containers, you have
problems with unsharing various pieces of namespace. But for the
pidspace, a simple function with clone() semantics makes perfect sense.
So your code does:

child_pid = pidspace_clone(pspace_id);
if (child_pid == 0) {
/* we are inside pspace 'pspace_id' with a random
pid which is unique in that pspace */
} else {
/* the child_pid is known by some other pid in it's
own pspace, but in our pspace it's known and hashed
by 'child_pid'. child_pid and that other pid are
likely different.

So long as we're just talking about the pidspaces, I don't see any
unexpected side effects here.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-02-17 15:56    [W:0.136 / U:1.588 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site