remote system call

remote system call

[Nitin Varyani]

Hi,
      I want to migrate user context of a process to a remote machine (i.e.
registers, code, data, virtual memory and program counter) and when it
makes a system call or file i/o, I want to send that request to its home
node.

That is, the user process executing at remote node will copy desired system
call number to %eax of home node and will execute 'int 0x80'. This will
generate interrupt 0x80 which should be sent to home node and an interrupt
service routine at home node will be called. This routine will execute in
ring 0 of home node.

A portion of process context which is system dependent has to be kept at
the home node.

That is, link to open files and link to kernel stack.

For eg: the following portion of the task_struct has to be kept at home node
/* filesystem information */
    struct fs_struct *fs;
/* open file information */
    struct files_struct *files;



Is it feasible? Can someone show some more light into it?

Nitin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160303/892eabc6/attachment.html 

remote system call

[Mulyadi Santosa]

On Thu, Mar 3, 2016 at 6:12 PM, Nitin Varyani <varyani.nitin1@gmail.com>
wrote:

> Hi,
>       I want to migrate user context of a process to a remote machine
> (i.e. registers, code, data, virtual memory and program counter) and when
> it makes a system call or file i/o, I want to send that request to its home
> node.
>
> That is, the user process executing at remote node will copy desired
> system call number to %eax of home node and will execute 'int 0x80'. This
> will generate interrupt 0x80 which should be sent to home node and an
> interrupt service routine at home node will be called. This routine will
> execute in ring 0 of home node.
>
> A portion of process context which is system dependent has to be kept at
> the home node.
>
> That is, link to open files and link to kernel stack.
>
> For eg: the following portion of the task_struct has to be kept at home
> node
> /* filesystem information */
>     struct fs_struct *fs;
> /* open file information */
>     struct files_struct *files;
>
>
>
> Is it feasible? Can someone show some more light into it?
>
> Nitin
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
Feasible, yes.

Try to check the source code of MOSIX/OpenMosix or OpenSSI.

Kerrighed is another project which done similar thing too.


-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160303/8061dd13/attachment-0001.html 

remote system call

[Nitin Varyani]

Codes are huge and documentation is negligible. How can I separate whay I
want to achieve from that big code?

On Thu, Mar 3, 2016 at 10:07 PM, Mulyadi Santosa <mulyadi.santosa@gmail.com>
wrote:

>
>
> On Thu, Mar 3, 2016 at 6:12 PM, Nitin Varyani <varyani.nitin1@gmail.com>
> wrote:
>
>> Hi,
>>       I want to migrate user context of a process to a remote machine
>> (i.e. registers, code, data, virtual memory and program counter) and when
>> it makes a system call or file i/o, I want to send that request to its home
>> node.
>>
>> That is, the user process executing at remote node will copy desired
>> system call number to %eax of home node and will execute 'int 0x80'. This
>> will generate interrupt 0x80 which should be sent to home node and an
>> interrupt service routine at home node will be called. This routine will
>> execute in ring 0 of home node.
>>
>> A portion of process context which is system dependent has to be kept at
>> the home node.
>>
>> That is, link to open files and link to kernel stack.
>>
>> For eg: the following portion of the task_struct has to be kept at home
>> node
>> /* filesystem information */
>>     struct fs_struct *fs;
>> /* open file information */
>>     struct files_struct *files;
>>
>>
>>
>> Is it feasible? Can someone show some more light into it?
>>
>> Nitin
>>
>> _______________________________________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.org
>> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>>
>>
> Feasible, yes.
>
> Try to check the source code of MOSIX/OpenMosix or OpenSSI.
>
> Kerrighed is another project which done similar thing too.
>
>
> --
> regards,
>
> Mulyadi Santosa
> Freelance Linux trainer and consultant
>
> blog: the-hydra.blogspot.com
> training: mulyaditraining.blogspot.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160305/a316914f/attachment.html 

remote system call

[Valdis.Kletnieks at vt.edu]

On Sat, 05 Mar 2016 15:58:13 +0530, Nitin Varyani said:
> Codes are huge and documentation is negligible. How can I separate whay I
> want to achieve from that big code?

Why do you think that's possible?

It's a lot more complicated problem to solve than you think.  Maybe
that huge code is necessary to achieve what you are trying to do.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 848 bytes
Desc: not available
Url : http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160305/4ada2ae2/attachment.bin 

remote system call

[Nicholas Mc Guire]

On Sat, Mar 05, 2016 at 04:58:07PM -0500, Valdis.Kletnieks at vt.edu wrote:
> On Sat, 05 Mar 2016 15:58:13 +0530, Nitin Varyani said:
> > Codes are huge and documentation is negligible. How can I separate whay I
> > want to achieve from that big code?
> 
> Why do you think that's possible?
> 
> It's a lot more complicated problem to solve than you think.  Maybe
> that huge code is necessary to achieve what you are trying to do.
> 

check bproc - it was a relatively simple solution (with some limitations)
far simpler than MOSIX - for 2.6.X kernels it worked really nicely
but Im not aware of the status http://bproc.sourceforge.net/
seems to be a bit dated.

thx!
hofrat