Re: [RFC] [PATCH 00/13] Introduce task_pid api

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Quoting Paul Jackson ([email protected]):
> Serge wrote:
> > Well a vserver pretends to be a full system of its own
> 
> Do you have any references, links?

Oh - linux-vserver.org

> > In fact this is one way we considered implementing the virtual pids -
> 
> No no - not what I meant.  I meant to have the pid be the same in all
> views, for all time, kernel and user, inside and outside the virtual
> server.  Just like pids are now.  A given virtual server would have
> a dedicated range of pids, reserved for it on all hardware systems
> in the farm.

But in the end isn't that more complicated than our approach?  The
kernel still needs to be modified to let processes request their pids,
and now processes have to worry *always* about the value or range of
their pids, both at startup and restart.  In the pidspace approach,
processes simply have a concept of starting a new pidspace, after
which the rest of the system processes are effectively gone as far as
this pidspace is concerned, and, other than that, processes continue
as normal.  Upon restart, they do have to reclaim their vpids, either
from userspace, or through in-kernel restart code.

-serge

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux