Attach my own pid

Pranay Srivastava pranjas at gmail.com
Mon Mar 21 23:22:19 EDT 2016


On Mon, Mar 21, 2016 at 4:34 PM, Nitin Varyani <varyani.nitin1 at gmail.com> wrote:
> struct task_struct {
> volatile long state;
> void *stack;
> ...
> pid_t pid;
> ...
> }
> You mean to say that just mapping the pid_t pid  will do the job. Does the
> linux kernel not store pid somewhere else while forking a child?

No I mean you can translate the pid chosen by kernel and then have a
policy to map it within your framework. That just translates onto a
possible different pid or may be same on another node. That way your
framework goes independent of what the kernel is doing.

Like for example nfs, translates the inode to a file handle internally
but that framework is independent of what happens on both nodes.

>
> On Mon, Mar 21, 2016 at 4:18 PM, Pranay Srivastava <pranjas at gmail.com>
> wrote:
>>
>> Nitin,
>>
>>
>> On Mon, Mar 21, 2016 at 4:03 PM, Nitin Varyani <varyani.nitin1 at gmail.com>
>> wrote:
>> > .....Continued.... That is, if kernel at Computer 2 finds that pid of a
>> > process requesting a system call is 1500, the request is forwarded to
>> > slave
>> > daemon which in turn contacts with the master daemon. Master daemon
>> > requests
>> > the kernel for the system call and sends the result back to slave
>> > daemon.
>>
>> I don't think doing this by pid is better. It might suit you currently
>> but in the long run?
>> If you are able to send the whole context, why not map that pid to
>> your context internally instead of relying
>> on pid which is also visible outside your context.
>>
>> >
>> > On Mon, Mar 21, 2016 at 4:01 PM, Nitin Varyani
>> > <varyani.nitin1 at gmail.com>
>> > wrote:
>> >>
>> >> I am trying to create a distributed pid space.
>> >>
>> >> 0 to 2000 Computer 1
>> >> 2001 to 4000 Computer 2
>> >> 4001 to 6000 Computer 3
>> >>
>>
>> your pid 2000 shouldn't have to be same pid 2000 on another node. You
>> just need the context right?
>>
>> >> and so on...
>> >>
>> >> I am running a master user-level process at Computer 1 which sends a
>> >> process context like code, data, registers, PC, etc as well as "pid" to
>> >> slave processes running at other computers. The responsibility of the
>> >> slave
>> >> process is to fork a new process on order of master process and attach
>> >> "pid"
>> >> given by the master to the new process it has forked. Any system call
>> >> on
>> >> slave nodes will have an initial check of " Whether the process belongs
>> >> to
>> >> local node or to the master node?". That is, if kernel at Computer 2
>> >> pid of
>> >> the process is 1500
>> >>
>> >>
>> >>
>> >> On Mon, Mar 21, 2016 at 12:23 PM, <Valdis.Kletnieks at vt.edu> wrote:
>> >>>
>> >>> On Mon, 21 Mar 2016 10:33:44 +0530, Nitin Varyani said:
>> >>>
>> >>> > Sub-task 1: Until now, parent process cannot control the pid of the
>> >>> > forked
>> >>> > child. A pid gets assigned as a sequential number by the kernel at
>> >>> > the
>> >>> > time
>> >>> > the process is forked . I want to modify kernel in such a way that
>> >>> > parent
>> >>> > process can control the pid of the forked child.
>> >>>
>> >>> What does controlling the pid gain you?  To what purpose?
>> >>>
>> >>> > Sub-task 2: On Linux, you can find the maximum PID value for your
>> >>> > system
>> >>> > with the following command:
>> >>> >
>> >>> > $ cat /proc/sys/kernel/pid_max
>> >>> >
>> >>> > Suppose pid_max=2000 for a system. I want that the parent process
>> >>> > should be
>> >>> > able to assign a pid which is greater that 2000 to the forked child.
>> >>>
>> >>> Again, why would you want to do that?
>> >>>
>> >>> Anyhow...
>> >>>
>> >>> echo 3000 > /proc/sys/kernel/pid_max
>> >>> fork a process that gets a pid over 2000.
>> >>>
>> >>> Done.
>> >>>
>> >>> Note that on 32 bit systems, using a pid_max of over 32768 will cause
>> >>> various things in /proc to blow up.
>> >>>
>> >>> I suspect that you need to think harder about what problem you're
>> >>> actually
>> >>> trying to solve here - what will you do with a controlled child PID?
>> >>> Why
>> >>> does
>> >>> it even matter?
>> >>
>> >>
>> >
>> >
>> > _______________________________________________
>> > Kernelnewbies mailing list
>> > Kernelnewbies at kernelnewbies.org
>> > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>> >
>>
>>
>>
>> --
>>         ---P.K.S
>
>



-- 
        ---P.K.S



More information about the Kernelnewbies mailing list