Re: [LTP] Patch to record kernel dump message to each testcases log

Re: [LTP] Patch to record kernel dump message to each testcases log

[hake huang]

[-- Attachment #1.1: Type: text/plain, Size: 582 bytes --]

Hi,

I wnat LTP to record the kernel dump message during each test case, and I
make a patch for this. Any comments?


@@ -1238,6 +1242,7 @@ write_test_end(struct tag_pgrp *running, const char
*init_status,
                int term_id, struct tms *tms1, struct tms *tms2)
 {
     if (!strcmp(reporttype, "rts")) {
+       system("/bin/dmesg -c");
        printf("%s\ninitiation_status=\"%s\"\nduration=%ld
termination_type=%s "
                "termination_id=%d corefile=%s\ncutime=%d cstime=%d\n%s\n",
                        "<<<execution_status>>>", init_status,

Regards,

Hake

[-- Attachment #1.2: Type: text/html, Size: 717 bytes --]

[-- Attachment #2: Type: text/plain, Size: 369 bytes --]

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[Garrett Cooper]

On Tue, Oct 12, 2010 at 5:56 AM, hake huang <hakehuang@gmail.com> wrote:
> Hi,
>
> I wnat LTP to record the kernel dump message during each test case, and I
> make a patch for this. Any comments?

Low:
1. This will break existing functionality (IIRC) with runltp provided
by Subrata (CCed for comment).

Medium:
2. It will bloat logs output on embedded systems / systems with limited space.
3. It could have other potential unwanted side-effects with tests
and/or system services (in particular because some people on the list
have been executing LTP on production systems, not testbed machines...
even though I argue that's their mistake).

High:
4. The change would confuse end-users.
5. The change would break scripts which parse the output in different
ways from what you intend.
6. Using system(3) to execute a program could yield some unintended
side-effects with file descriptors, terminal handling, process
wait(2)ing, etc.

Thanks,
-Garrett

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[hake huang]

[-- Attachment #1.1: Type: text/plain, Size: 1823 bytes --]

Hi

I see this simple solution is no quite fit. But the kernel dump message for
each test case is necessary for analysing. I can work on this further, with
below help:
1. Where can I find the reason for the IIRC break?
2. Can it  be an option to avoid the size limitation on some embedded
system?
3.  A kind of seperating tag is needed for kernel message, right? e.g
<kernel_dump_start>dump message<kernel_dump_end>
4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
process. if the system(3) has problem, the worst cases is there are no
kernel messge output in parent process, but the pan can still function well.

if not use system(3), can you give your suggestion on this, exec(3) seems to
have the same problem as system(3)?

Regards,

Hake

2010/10/13 Garrett Cooper <yanegomi@gmail.com>

> On Tue, Oct 12, 2010 at 5:56 AM, hake huang <hakehuang@gmail.com> wrote:
> > Hi,
> >
> > I wnat LTP to record the kernel dump message during each test case, and I
> > make a patch for this. Any comments?
>
> Low:
> 1. This will break existing functionality (IIRC) with runltp provided
> by Subrata (CCed for comment).
>
> Medium:
> 2. It will bloat logs output on embedded systems / systems with limited
> space.
> 3. It could have other potential unwanted side-effects with tests
> and/or system services (in particular because some people on the list
> have been executing LTP on production systems, not testbed machines...
> even though I argue that's their mistake).
>
> High:
> 4. The change would confuse end-users.
> 5. The change would break scripts which parse the output in different
> ways from what you intend.
> 6. Using system(3) to execute a program could yield some unintended
> side-effects with file descriptors, terminal handling, process
> wait(2)ing, etc.
>
> Thanks,
> -Garrett
>

[-- Attachment #1.2: Type: text/html, Size: 2332 bytes --]

[-- Attachment #2: Type: text/plain, Size: 369 bytes --]

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb

[-- Attachment #3: Type: text/plain, Size: 155 bytes --]

_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[Garrett Cooper]

On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> Hi
>
> I see this simple solution is no quite fit. But the kernel dump message for
> each test case is necessary for analysing. I can work on this further, with
> below help:
> 1. Where can I find the reason for the IIRC break?

IIRC -> If I remember correctly.

> 2. Can it  be an option to avoid the size limitation on some embedded
> system?

No. This is outside the realm of LTP, but we must remain conscious of
the fact that there are folks running LTP on cellphones, etc, where
space is very much a luxury.

> 3.  A kind of seperating tag is needed for kernel message, right? e.g
> <kernel_dump_start>dump message<kernel_dump_end>

I think that adding an optional capture feature might be worthwhile,
but you'll no doubt quickly find with some processes that the dmesg
buffer will fill up quickly.

> 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
> process. if the system(3) has problem, the worst cases is there are no
> kernel messge output in parent process, but the pan can still function well.

Can you say that with 100% certainty? One of the potential problems
with system is the fact that it allocates a shell and depending on how
processes are executed and how file descriptors are cleaned up,

Actually, pan makes zero attempts at closing open file descriptors and
the like, so the problem is still very much with pan.

> if not use system(3), can you give your suggestion on this, exec(3) seems to
> have the same problem as system(3)?

Yes and no. In this case the problems that exist with open file
descriptor inheritance, etc are unfortunately no worse from that
perspective than your proposed code would do, but there are still
other problems that need to be resolved with your proposed change
anyhow that are much more pressing.

-Garrett

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[hake huang]

2010/10/13 Garrett Cooper <yanegomi@gmail.com>
>
> On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> > Hi
> >
> > I see this simple solution is no quite fit. But the kernel dump message for
> > each test case is necessary for analysing. I can work on this further, with
> > below help:
> > 1. Where can I find the reason for the IIRC break?
>
> IIRC -> If I remember correctly.
so I need ask Subrata about this problem, right? what is the existing
functionality?
>
> > 2. Can it  be an option to avoid the size limitation on some embedded
> > system?
>
> No. This is outside the realm of LTP, but we must remain conscious of
> the fact that there are folks running LTP on cellphones, etc, where
> space is very much a luxury.
I see. but why can't they run in quit_mode?
>
> > 3.  A kind of seperating tag is needed for kernel message, right? e.g
> > <kernel_dump_start>dump message<kernel_dump_end>
>
> I think that adding an optional capture feature might be worthwhile,
> but you'll no doubt quickly find with some processes that the dmesg
> buffer will fill up quickly.
I have seen such events, and such cases need to be checked manually.
>
> > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
> > process. if the system(3) has problem, the worst cases is there are no
> > kernel messge output in parent process, but the pan can still function well.
>
> Can you say that with 100% certainty? One of the potential problems
> with system is the fact that it allocates a shell and depending on how
> processes are executed and how file descriptors are cleaned up,
>
> Actually, pan makes zero attempts at closing open file descriptors and
> the like, so the problem is still very much with pan.
>
So your concerns is about file descriptors which open in ltp process,
I think this is an existing problem. I mean maybe pan need to attempt
to close open file descriptors. system(3) only increases the change of
occurrence caused by this problem, right?
> > if not use system(3), can you give your suggestion on this, exec(3) seems to
> > have the same problem as system(3)?
>
> Yes and no. In this case the problems that exist with open file
> descriptor inheritance, etc are unfortunately no worse from that
> perspective than your proposed code would do, but there are still
> other problems that need to be resolved with your proposed change
> anyhow that are much more pressing.
>
> -Garrett

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[Subrata Modak]

On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
> 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
> >
> > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> > > Hi
> > >
> > > I see this simple solution is no quite fit. But the kernel dump message for
> > > each test case is necessary for analysing. I can work on this further, with
> > > below help:
> > > 1. Where can I find the reason for the IIRC break?
> >
> > IIRC -> If I remember correctly.
> so I need ask Subrata about this problem, right? what is the existing
> functionality?

I believe the functionality your original patch was proposing is already
in LTP . I guess they will solve your problem. See the following
commits:

git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3

Just use:

./runltp -K <DMESG_DIRECTORY_NAME>

option while running ltp.

Regards--
Subrata

> >
> > > 2. Can it  be an option to avoid the size limitation on some embedded
> > > system?
> >
> > No. This is outside the realm of LTP, but we must remain conscious of
> > the fact that there are folks running LTP on cellphones, etc, where
> > space is very much a luxury.
> I see. but why can't they run in quit_mode?
> >
> > > 3.  A kind of seperating tag is needed for kernel message, right? e.g
> > > <kernel_dump_start>dump message<kernel_dump_end>
> >
> > I think that adding an optional capture feature might be worthwhile,
> > but you'll no doubt quickly find with some processes that the dmesg
> > buffer will fill up quickly.
> I have seen such events, and such cases need to be checked manually.
> >
> > > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
> > > process. if the system(3) has problem, the worst cases is there are no
> > > kernel messge output in parent process, but the pan can still function well.
> >
> > Can you say that with 100% certainty? One of the potential problems
> > with system is the fact that it allocates a shell and depending on how
> > processes are executed and how file descriptors are cleaned up,
> >
> > Actually, pan makes zero attempts at closing open file descriptors and
> > the like, so the problem is still very much with pan.
> >
> So your concerns is about file descriptors which open in ltp process,
> I think this is an existing problem. I mean maybe pan need to attempt
> to close open file descriptors. system(3) only increases the change of
> occurrence caused by this problem, right?
> > > if not use system(3), can you give your suggestion on this, exec(3) seems to
> > > have the same problem as system(3)?
> >
> > Yes and no. In this case the problems that exist with open file
> > descriptor inheritance, etc are unfortunately no worse from that
> > perspective than your proposed code would do, but there are still
> > other problems that need to be resolved with your proposed change
> > anyhow that are much more pressing.
> >
> > -Garrett


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[Subrata Modak]

On Wed, 2010-10-13 at 12:22 +0530, Subrata Modak wrote:
> On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
> > 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
> > >
> > > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> > > > Hi
> > > >
> > > > I see this simple solution is no quite fit. But the kernel dump message for
> > > > each test case is necessary for analysing. I can work on this further, with
> > > > below help:
> > > > 1. Where can I find the reason for the IIRC break?
> > >
> > > IIRC -> If I remember correctly.
> > so I need ask Subrata about this problem, right? what is the existing
> > functionality?
> 
> I believe the functionality your original patch was proposing is already
> in LTP . I guess they will solve your problem. See the following
> commits:
> 
> git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
> git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3
> 
> Just use:
> 
> ./runltp -K <DMESG_DIRECTORY_NAME>

Basically, its a choice given to users who would like to record the
kernel messages, and not forcing recording all kernel messages which
your original patch is proposing :-)

Regards--
Subrata

> 
> option while running ltp.
> 
> Regards--
> Subrata
> 
> > >
> > > > 2. Can it  be an option to avoid the size limitation on some embedded
> > > > system?
> > >
> > > No. This is outside the realm of LTP, but we must remain conscious of
> > > the fact that there are folks running LTP on cellphones, etc, where
> > > space is very much a luxury.
> > I see. but why can't they run in quit_mode?
> > >
> > > > 3.  A kind of seperating tag is needed for kernel message, right? e.g
> > > > <kernel_dump_start>dump message<kernel_dump_end>
> > >
> > > I think that adding an optional capture feature might be worthwhile,
> > > but you'll no doubt quickly find with some processes that the dmesg
> > > buffer will fill up quickly.
> > I have seen such events, and such cases need to be checked manually.
> > >
> > > > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
> > > > process. if the system(3) has problem, the worst cases is there are no
> > > > kernel messge output in parent process, but the pan can still function well.
> > >
> > > Can you say that with 100% certainty? One of the potential problems
> > > with system is the fact that it allocates a shell and depending on how
> > > processes are executed and how file descriptors are cleaned up,
> > >
> > > Actually, pan makes zero attempts at closing open file descriptors and
> > > the like, so the problem is still very much with pan.
> > >
> > So your concerns is about file descriptors which open in ltp process,
> > I think this is an existing problem. I mean maybe pan need to attempt
> > to close open file descriptors. system(3) only increases the change of
> > occurrence caused by this problem, right?
> > > > if not use system(3), can you give your suggestion on this, exec(3) seems to
> > > > have the same problem as system(3)?
> > >
> > > Yes and no. In this case the problems that exist with open file
> > > descriptor inheritance, etc are unfortunately no worse from that
> > > perspective than your proposed code would do, but there are still
> > > other problems that need to be resolved with your proposed change
> > > anyhow that are much more pressing.
> > >
> > > -Garrett
> 
> 
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[hake huang]

Hi Subrata,

one question:
-K will only record all kernel message, but can not match each testcase, right?

Regards,

Hake

2010/10/13 Subrata Modak <subrata@linux.vnet.ibm.com>:
> On Wed, 2010-10-13 at 12:22 +0530, Subrata Modak wrote:
>> On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
>> > 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
>> > >
>> > > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
>> > > > Hi
>> > > >
>> > > > I see this simple solution is no quite fit. But the kernel dump message for
>> > > > each test case is necessary for analysing. I can work on this further, with
>> > > > below help:
>> > > > 1. Where can I find the reason for the IIRC break?
>> > >
>> > > IIRC -> If I remember correctly.
>> > so I need ask Subrata about this problem, right? what is the existing
>> > functionality?
>>
>> I believe the functionality your original patch was proposing is already
>> in LTP . I guess they will solve your problem. See the following
>> commits:
>>
>> git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
>> git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3
>>
>> Just use:
>>
>> ./runltp -K <DMESG_DIRECTORY_NAME>
>
> Basically, its a choice given to users who would like to record the
> kernel messages, and not forcing recording all kernel messages which
> your original patch is proposing :-)
>
> Regards--
> Subrata
>
>>
>> option while running ltp.
>>
>> Regards--
>> Subrata
>>
>> > >
>> > > > 2. Can it  be an option to avoid the size limitation on some embedded
>> > > > system?
>> > >
>> > > No. This is outside the realm of LTP, but we must remain conscious of
>> > > the fact that there are folks running LTP on cellphones, etc, where
>> > > space is very much a luxury.
>> > I see. but why can't they run in quit_mode?
>> > >
>> > > > 3.  A kind of seperating tag is needed for kernel message, right? e.g
>> > > > <kernel_dump_start>dump message<kernel_dump_end>
>> > >
>> > > I think that adding an optional capture feature might be worthwhile,
>> > > but you'll no doubt quickly find with some processes that the dmesg
>> > > buffer will fill up quickly.
>> > I have seen such events, and such cases need to be checked manually.
>> > >
>> > > > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
>> > > > process. if the system(3) has problem, the worst cases is there are no
>> > > > kernel messge output in parent process, but the pan can still function well.
>> > >
>> > > Can you say that with 100% certainty? One of the potential problems
>> > > with system is the fact that it allocates a shell and depending on how
>> > > processes are executed and how file descriptors are cleaned up,
>> > >
>> > > Actually, pan makes zero attempts at closing open file descriptors and
>> > > the like, so the problem is still very much with pan.
>> > >
>> > So your concerns is about file descriptors which open in ltp process,
>> > I think this is an existing problem. I mean maybe pan need to attempt
>> > to close open file descriptors. system(3) only increases the change of
>> > occurrence caused by this problem, right?
>> > > > if not use system(3), can you give your suggestion on this, exec(3) seems to
>> > > > have the same problem as system(3)?
>> > >
>> > > Yes and no. In this case the problems that exist with open file
>> > > descriptor inheritance, etc are unfortunately no worse from that
>> > > perspective than your proposed code would do, but there are still
>> > > other problems that need to be resolved with your proposed change
>> > > anyhow that are much more pressing.
>> > >
>> > > -Garrett
>>
>>
>> ------------------------------------------------------------------------------
>> Beautiful is writing same markup. Internet Explorer 9 supports
>> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> Spend less time writing and  rewriting code and more time creating great
>> experiences on the web. Be a part of the beta today.
>> http://p.sf.net/sfu/beautyoftheweb
>> _______________________________________________
>> Ltp-list mailing list
>> Ltp-list@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ltp-list
>
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[Subrata Modak]

On Wed, 2010-10-13 at 15:00 +0800, hake huang wrote:
> Hi Subrata,
> 
> one question:
> -K will only record all kernel message, but can not match each testcase, right?

It will record kernel messages for each individual test case by
recording it inside ltp*/output/<DMESG_DIR_NAME>/<testname>.dmeg

Once test run is over it will delete all .dmeg* files of zero size and
will retain only those having real entries. So, you will get exactly
which tests generated kernel messages and what the messages exactly are
for each individual test.

Regards--
Subrata

> 
> Regards,
> 
> Hake
> 
> 2010/10/13 Subrata Modak <subrata@linux.vnet.ibm.com>:
> > On Wed, 2010-10-13 at 12:22 +0530, Subrata Modak wrote:
> >> On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
> >> > 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
> >> > >
> >> > > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
> >> > > > Hi
> >> > > >
> >> > > > I see this simple solution is no quite fit. But the kernel dump message for
> >> > > > each test case is necessary for analysing. I can work on this further, with
> >> > > > below help:
> >> > > > 1. Where can I find the reason for the IIRC break?
> >> > >
> >> > > IIRC -> If I remember correctly.
> >> > so I need ask Subrata about this problem, right? what is the existing
> >> > functionality?
> >>
> >> I believe the functionality your original patch was proposing is already
> >> in LTP . I guess they will solve your problem. See the following
> >> commits:
> >>
> >> git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
> >> git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3
> >>
> >> Just use:
> >>
> >> ./runltp -K <DMESG_DIRECTORY_NAME>
> >
> > Basically, its a choice given to users who would like to record the
> > kernel messages, and not forcing recording all kernel messages which
> > your original patch is proposing :-)
> >
> > Regards--
> > Subrata
> >
> >>
> >> option while running ltp.
> >>
> >> Regards--
> >> Subrata
> >>
> >> > >
> >> > > > 2. Can it  be an option to avoid the size limitation on some embedded
> >> > > > system?
> >> > >
> >> > > No. This is outside the realm of LTP, but we must remain conscious of
> >> > > the fact that there are folks running LTP on cellphones, etc, where
> >> > > space is very much a luxury.
> >> > I see. but why can't they run in quit_mode?
> >> > >
> >> > > > 3.  A kind of seperating tag is needed for kernel message, right? e.g
> >> > > > <kernel_dump_start>dump message<kernel_dump_end>
> >> > >
> >> > > I think that adding an optional capture feature might be worthwhile,
> >> > > but you'll no doubt quickly find with some processes that the dmesg
> >> > > buffer will fill up quickly.
> >> > I have seen such events, and such cases need to be checked manually.
> >> > >
> >> > > > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
> >> > > > process. if the system(3) has problem, the worst cases is there are no
> >> > > > kernel messge output in parent process, but the pan can still function well.
> >> > >
> >> > > Can you say that with 100% certainty? One of the potential problems
> >> > > with system is the fact that it allocates a shell and depending on how
> >> > > processes are executed and how file descriptors are cleaned up,
> >> > >
> >> > > Actually, pan makes zero attempts at closing open file descriptors and
> >> > > the like, so the problem is still very much with pan.
> >> > >
> >> > So your concerns is about file descriptors which open in ltp process,
> >> > I think this is an existing problem. I mean maybe pan need to attempt
> >> > to close open file descriptors. system(3) only increases the change of
> >> > occurrence caused by this problem, right?
> >> > > > if not use system(3), can you give your suggestion on this, exec(3) seems to
> >> > > > have the same problem as system(3)?
> >> > >
> >> > > Yes and no. In this case the problems that exist with open file
> >> > > descriptor inheritance, etc are unfortunately no worse from that
> >> > > perspective than your proposed code would do, but there are still
> >> > > other problems that need to be resolved with your proposed change
> >> > > anyhow that are much more pressing.
> >> > >
> >> > > -Garrett
> >>
> >>
> >> ------------------------------------------------------------------------------
> >> Beautiful is writing same markup. Internet Explorer 9 supports
> >> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> >> Spend less time writing and  rewriting code and more time creating great
> >> experiences on the web. Be a part of the beta today.
> >> http://p.sf.net/sfu/beautyoftheweb
> >> _______________________________________________
> >> Ltp-list mailing list
> >> Ltp-list@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/ltp-list
> >
> >


------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

Re: [LTP] Patch to record kernel dump message to each testcases log

[hake huang]

very clear thanks.

2010/10/13 Subrata Modak <subrata@linux.vnet.ibm.com>:
> On Wed, 2010-10-13 at 15:00 +0800, hake huang wrote:
>> Hi Subrata,
>>
>> one question:
>> -K will only record all kernel message, but can not match each testcase, right?
>
> It will record kernel messages for each individual test case by
> recording it inside ltp*/output/<DMESG_DIR_NAME>/<testname>.dmeg
>
> Once test run is over it will delete all .dmeg* files of zero size and
> will retain only those having real entries. So, you will get exactly
> which tests generated kernel messages and what the messages exactly are
> for each individual test.
>
> Regards--
> Subrata
>
>>
>> Regards,
>>
>> Hake
>>
>> 2010/10/13 Subrata Modak <subrata@linux.vnet.ibm.com>:
>> > On Wed, 2010-10-13 at 12:22 +0530, Subrata Modak wrote:
>> >> On Wed, 2010-10-13 at 13:30 +0800, hake huang wrote:
>> >> > 2010/10/13 Garrett Cooper <yanegomi@gmail.com>
>> >> > >
>> >> > > On Tue, Oct 12, 2010 at 9:38 PM, hake huang <hakehuang@gmail.com> wrote:
>> >> > > > Hi
>> >> > > >
>> >> > > > I see this simple solution is no quite fit. But the kernel dump message for
>> >> > > > each test case is necessary for analysing. I can work on this further, with
>> >> > > > below help:
>> >> > > > 1. Where can I find the reason for the IIRC break?
>> >> > >
>> >> > > IIRC -> If I remember correctly.
>> >> > so I need ask Subrata about this problem, right? what is the existing
>> >> > functionality?
>> >>
>> >> I believe the functionality your original patch was proposing is already
>> >> in LTP . I guess they will solve your problem. See the following
>> >> commits:
>> >>
>> >> git show e3bc3758d3e4d17a0e04009ef873df53819b9ec6
>> >> git show bd9d440be1da8020c93ac92e497e3a16e66e9fa3
>> >>
>> >> Just use:
>> >>
>> >> ./runltp -K <DMESG_DIRECTORY_NAME>
>> >
>> > Basically, its a choice given to users who would like to record the
>> > kernel messages, and not forcing recording all kernel messages which
>> > your original patch is proposing :-)
>> >
>> > Regards--
>> > Subrata
>> >
>> >>
>> >> option while running ltp.
>> >>
>> >> Regards--
>> >> Subrata
>> >>
>> >> > >
>> >> > > > 2. Can it  be an option to avoid the size limitation on some embedded
>> >> > > > system?
>> >> > >
>> >> > > No. This is outside the realm of LTP, but we must remain conscious of
>> >> > > the fact that there are folks running LTP on cellphones, etc, where
>> >> > > space is very much a luxury.
>> >> > I see. but why can't they run in quit_mode?
>> >> > >
>> >> > > > 3.  A kind of seperating tag is needed for kernel message, right? e.g
>> >> > > > <kernel_dump_start>dump message<kernel_dump_end>
>> >> > >
>> >> > > I think that adding an optional capture feature might be worthwhile,
>> >> > > but you'll no doubt quickly find with some processes that the dmesg
>> >> > > buffer will fill up quickly.
>> >> > I have seen such events, and such cases need to be checked manually.
>> >> > >
>> >> > > > 4.  I see in ltp-pan.c the file descriptors, terminals are changed in child
>> >> > > > process. if the system(3) has problem, the worst cases is there are no
>> >> > > > kernel messge output in parent process, but the pan can still function well.
>> >> > >
>> >> > > Can you say that with 100% certainty? One of the potential problems
>> >> > > with system is the fact that it allocates a shell and depending on how
>> >> > > processes are executed and how file descriptors are cleaned up,
>> >> > >
>> >> > > Actually, pan makes zero attempts at closing open file descriptors and
>> >> > > the like, so the problem is still very much with pan.
>> >> > >
>> >> > So your concerns is about file descriptors which open in ltp process,
>> >> > I think this is an existing problem. I mean maybe pan need to attempt
>> >> > to close open file descriptors. system(3) only increases the change of
>> >> > occurrence caused by this problem, right?
>> >> > > > if not use system(3), can you give your suggestion on this, exec(3) seems to
>> >> > > > have the same problem as system(3)?
>> >> > >
>> >> > > Yes and no. In this case the problems that exist with open file
>> >> > > descriptor inheritance, etc are unfortunately no worse from that
>> >> > > perspective than your proposed code would do, but there are still
>> >> > > other problems that need to be resolved with your proposed change
>> >> > > anyhow that are much more pressing.
>> >> > >
>> >> > > -Garrett
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Beautiful is writing same markup. Internet Explorer 9 supports
>> >> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
>> >> Spend less time writing and  rewriting code and more time creating great
>> >> experiences on the web. Be a part of the beta today.
>> >> http://p.sf.net/sfu/beautyoftheweb
>> >> _______________________________________________
>> >> Ltp-list mailing list
>> >> Ltp-list@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/ltp-list
>> >
>> >
>
>

------------------------------------------------------------------------------
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list