On Thu, Mar 3, 2016 at 10:07 PM, <kernelnewbies-request@xxxxxxxxxxxxxxxxx> wrote:
Send Kernelnewbies mailing list submissions toIt seems to be a valid change and should be accepted in the kernel.
kernelnewbies@xxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
or, via email, send a message with subject or body 'help' to
kernelnewbies-request@xxxxxxxxxxxxxxxxx
You can reach the person managing the list at
kernelnewbies-owner@xxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Kernelnewbies digest..."
Today's Topics:
1. Re: Submitting patches to non-staging (Christoph Lameter)
2. Re: Submitting patches to non-staging (Pratyush Patel)
3. Fw: new important message (bear.yogi@xxxxxx)
4. Re: where is disk block access in kernel ? (Mulyadi Santosa)
5. Re: where is disk block access in kernel ?
(Valdis.Kletnieks@xxxxxx)
6. remote system call (Nitin Varyani)
7. Re: remote system call (Mulyadi Santosa)
----------------------------------------------------------------------
Message: 1
Date: Wed, 2 Mar 2016 13:45:54 -0600 (CST)
From: Christoph Lameter <cl@xxxxxxxxx>
Subject: Re: Submitting patches to non-staging
To: Pratyush Patel <pratyushpatel.1995@xxxxxxxxx>
Cc: kernelnewbies@xxxxxxxxxxxxxxxxx
Message-ID: <alpine.DEB.2.20.1603021344420.3497@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII
On Tue, 1 Mar 2016, Pratyush Patel wrote:
> I will be pursuing my undergraduate thesis research in the field of
> real-time (operating) systems and as such, I expect to be closely
> involved with the timer and interrupt subsystems in Linux (as well as
> other areas, but to a lesser degree). I am also hoping to work with
> the hrtimer subsystem, and while going through the latest code
> (4.5-rc6) of the same, I found a very minor code-level change that
> could be incorporated (redundant #ifdef). Would such a change in a
> core kernel file be acceptable coming from a beginner? Or should I aim
> for the staging drivers first?
Dont worry about staging. There is no staing for interrupts and timers. Go
direct and post to the relevant maintainers and lkml
> I very much look forward to contributing my first patch!
love to see it.
------------------------------
Message: 2
Date: Thu, 3 Mar 2016 07:20:18 +0530
From: Pratyush Patel <pratyushpatel.1995@xxxxxxxxx>
Subject: Re: Submitting patches to non-staging
To: Christoph Lameter <cl@xxxxxxxxx>
Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
<CAAnMKKbXAKUDHXx7Mf-npnM1BRWVbNoA=BcZFB-xu5r6Ay46dA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
On Thu, Mar 3, 2016 at 1:15 AM, Christoph Lameter <cl@xxxxxxxxx> wrote:
> On Tue, 1 Mar 2016, Pratyush Patel wrote:
>
>> I will be pursuing my undergraduate thesis research in the field of
>> real-time (operating) systems and as such, I expect to be closely
>> involved with the timer and interrupt subsystems in Linux (as well as
>> other areas, but to a lesser degree). I am also hoping to work with
>> the hrtimer subsystem, and while going through the latest code
>> (4.5-rc6) of the same, I found a very minor code-level change that
>> could be incorporated (redundant #ifdef). Would such a change in a
>> core kernel file be acceptable coming from a beginner? Or should I aim
>> for the staging drivers first?
>
> Dont worry about staging. There is no staing for interrupts and timers. Go
> direct and post to the relevant maintainers and lkml
>
>> I very much look forward to contributing my first patch!
>
> love to see it.
>
Here's the archive link: http://comments.gmane.org/gmane.linux.kernel/2165466
Please do let me know in case I did something wrongly.
Awaiting for it to be accepted!
You may probably change the commit message something like..
" removing nested macro definition (CONFIG_SMP)" if you want.
good luck
-- Vishwas
------------------------------
Message: 3
Date: Thu, 3 Mar 2016 05:37:11 +0300
From: <bear.yogi@xxxxxx>
Subject: Fw: new important message
To: "kernelnewbies" <kernelnewbies@xxxxxxxxxxxxxxxxx>, "leo kirotawa"
<kirotawa@xxxxxxxxx>, "lifelong0811" <lifelong0811@xxxxxxx>,
"lind.lampe@xxxxxx" <lind.lampe@xxxxxx>, "linux-api"
<linux-api@xxxxxxxxxxxxxxx>
Message-ID: <0000073edf2f$53e14ef2$6fb257ae$@gmx.de>
Content-Type: text/plain; charset="us-ascii"
Hello!
New message, please read <http://majorinvesting.com/longer.php?drpr>
bear.yogi@xxxxxx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160303/043f8012/attachment-0001.html
------------------------------
Message: 4
Date: Thu, 3 Mar 2016 13:18:42 +0700
From: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>
Subject: Re: where is disk block access in kernel ?
Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
<CAGdaadaDSooo8f7LBO-v09kO8qmfh4pZ58VsVY0E+2fqqQhJHw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Wed, Mar 2, 2016 at 4:57 PM, Ran Shalit <ranshalit@xxxxxxxxx> wrote:
> Hello,
>
> I would like to monitor the write access to disk blocks (so that I can
> monitor the block index in some bitmap)
> I think this must be done in kernel (userspace have no such information)
> I have tried to search in kernel but did not found where is the API to
> access disk blocks.
> There is libata-core.c , but I can't find such routines there, and
> neither any documentation.
>
> Is there any idea ?
>
> Regards,
> Ran
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies@xxxxxxxxxxxxxxxxx
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
Hi
Sounds like something doable via ftrace.
try to check if it is feasible to be done using ftrace
--
regards,
Mulyadi Santosa
Freelance Linux trainer and consultant
blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com
This email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160303/490aed0f/attachment-0001.html
------------------------------
Message: 5
Date: Thu, 03 Mar 2016 02:09:39 -0500
From: Valdis.Kletnieks@xxxxxx
Subject: Re: where is disk block access in kernel ?
To: Ran Shalit <ranshalit@xxxxxxxxx>
Cc: kernelnewbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID: <13529.1456988979@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
On Wed, 02 Mar 2016 11:57:41 +0200, Ran Shalit said:
> I would like to monitor the write access to disk blocks (so that I can
> monitor the block index in some bitmap)
What exactly are you trying to do with that information? (Hint - figure out
how big a bitmap you need for the blocks on a 2T or 4T drive - or for the
600T to petabyte filesystems I deal with for a living).
Do you need just write access, or read as well?
Do you need the info before or after the disk cache is involved?
Do you need to deal with corner cases like a program writing to a file, and
then unlinking the file before the blocks are written to disk?
As is common for kernel issues, the answer depends a lot on exactly what
the *real* question is....
-------------- 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/20160303/67a25edc/attachment-0001.bin
------------------------------
Message: 6
Date: Thu, 3 Mar 2016 16:42:24 +0530
From: Nitin Varyani <varyani.nitin1@xxxxxxxxx>
Subject: remote system call
To: Kernel Newbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
<CAKfJ7KJCacyJyNeokCxG5rNCMB-j3bvu83YYe_pUYVofgTombg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
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-0001.html
------------------------------
Message: 7
Date: Thu, 3 Mar 2016 23:37:11 +0700
From: Mulyadi Santosa <mulyadi.santosa@xxxxxxxxx>
Subject: Re: remote system call
To: Nitin Varyani <varyani.nitin1@xxxxxxxxx>
Cc: Kernel Newbies <kernelnewbies@xxxxxxxxxxxxxxxxx>
Message-ID:
<CAGdaadZF-f7h6eEFW=RsVrexorpudYawydPE2ibZLGzWOVzcQg@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Thu, Mar 3, 2016 at 6:12 PM, Nitin Varyani <varyani.nitin1@xxxxxxxxx>
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@xxxxxxxxxxxxxxxxx
> 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.html
------------------------------
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
End of Kernelnewbies Digest, Vol 64, Issue 4
********************************************
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
