Kernelnewbies Digest, Vol 64, Issue 4
Vishwas Srivastava
vishu.kernel at gmail.com
Fri Mar 4 01:52:30 EST 2016
On Thu, Mar 3, 2016 at 10:07 PM, <kernelnewbies-request at kernelnewbies.org>
wrote:
> Send Kernelnewbies mailing list submissions to
> kernelnewbies at kernelnewbies.org
>
> 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 at kernelnewbies.org
>
> You can reach the person managing the list at
> kernelnewbies-owner at kernelnewbies.org
>
> 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 at gmx.de)
> 4. Re: where is disk block access in kernel ? (Mulyadi Santosa)
> 5. Re: where is disk block access in kernel ?
> (Valdis.Kletnieks at vt.edu)
> 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 at linux.com>
> Subject: Re: Submitting patches to non-staging
> To: Pratyush Patel <pratyushpatel.1995 at gmail.com>
> Cc: kernelnewbies at kernelnewbies.org
> Message-ID: <alpine.DEB.2.20.1603021344420.3497 at east.gentwo.org>
> 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 at gmail.com>
> Subject: Re: Submitting patches to non-staging
> To: Christoph Lameter <cl at linux.com>
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CAAnMKKbXAKUDHXx7Mf-npnM1BRWVbNoA=
> BcZFB-xu5r6Ay46dA at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Mar 3, 2016 at 1:15 AM, Christoph Lameter <cl at linux.com> 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!
>
> It seems to be a valid change and should be accepted in the kernel.
>
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 at gmx.de>
> Subject: Fw: new important message
> To: "kernelnewbies" <kernelnewbies at kernelnewbies.org>, "leo kirotawa"
> <kirotawa at gmail.com>, "lifelong0811" <lifelong0811 at 126.com>,
> "lind.lampe at gmx.de" <lind.lampe at gmx.de>, "linux-api"
> <linux-api at vger.kernel.org>
> 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 at gmx.de
>
> -------------- 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 at gmail.com>
> Subject: Re: where is disk block access in kernel ?
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <
> CAGdaadaDSooo8f7LBO-v09kO8qmfh4pZ58VsVY0E+2fqqQhJHw at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Wed, Mar 2, 2016 at 4:57 PM, Ran Shalit <ranshalit at gmail.com> 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 at kernelnewbies.org
> > 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 at vt.edu
> Subject: Re: where is disk block access in kernel ?
> To: Ran Shalit <ranshalit at gmail.com>
> Cc: kernelnewbies <kernelnewbies at kernelnewbies.org>
> Message-ID: <13529.1456988979 at turing-police.cc.vt.edu>
> 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 at gmail.com>
> Subject: remote system call
> To: Kernel Newbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <
> CAKfJ7KJCacyJyNeokCxG5rNCMB-j3bvu83YYe_pUYVofgTombg at mail.gmail.com>
> 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 at gmail.com>
> Subject: Re: remote system call
> To: Nitin Varyani <varyani.nitin1 at gmail.com>
> Cc: Kernel Newbies <kernelnewbies at kernelnewbies.org>
> Message-ID:
> <CAGdaadZF-f7h6eEFW=
> RsVrexorpudYawydPE2ibZLGzWOVzcQg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Thu, Mar 3, 2016 at 6:12 PM, Nitin Varyani <varyani.nitin1 at 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.html
>
> ------------------------------
>
> _______________________________________________
> Kernelnewbies mailing list
> Kernelnewbies at kernelnewbies.org
> http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
>
>
> End of Kernelnewbies Digest, Vol 64, Issue 4
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160304/39659ec4/attachment-0001.html
More information about the Kernelnewbies
mailing list