On Thu, 2006-12-21 at 10:49 -0500, Ming Zhang wrote:

<snip>

> > 
> > That's fine with me, I'm not suggesting an elaborate scheme. I just want
> > to prevent people accidentally doin foo.blktrace.0 from missing events
> > from CPUs 1...N. So:
> > 
> > * - for stdin
> > 
> > * 'x' is a fifo, open that.
> > 
> > * foo and foo.blktrace.[0...N] exists, open foo.blktrace.[0...N]
> > 
> > Up until now, that is no change from what blkparse currently does, I'm
> > just describing it. So the new rule I'm proposing is:
> > 
> > * foo.blktrace.0 given, and foo.blktrace.[1...N] exists, print a warning
> >   and add those files.
> > 
> > If someone really wants to use only that file (obscure case, I cannot
> > imagine a real world scenario where that is the case. The weird HT
> > experimentation case that Seelam gave is easy - just delete the damn
> > file, it wont even be valid anymore since the first file is
> > overwritten), then they can use '-' as input and cat the file.
> > 
> 
> no warning is given. add silently for 4th.

any comment about this patch?


> 
> diff --git a/blkparse.c b/blkparse.c
> index 6bb5308..11e81c6 100644
> --- a/blkparse.c
> +++ b/blkparse.c
> @@ -2307,9 +2307,22 @@ static int handle(struct ms_stream *msp)
>       return 1;
>  }
>  
> +static int name_check(char *name)
> +{
> +     char *b;
> +
> +     if (!name)
> +             return -EINVAL;
> +
> +     b = strstr(name, ".blktrace.");
> +     if (b)
> +             *b = '\0';
> +     return 0;
> +}
> +
>  static int do_file(void)
>  {
> -     int i, cpu;
> +     int i, cpu, res;
>       struct per_dev_info *pdi;
>  
>       /*
> @@ -2317,6 +2330,9 @@ static int do_file(void)
>        */
>       for (i = 0; i < ndevices; i++) {
>               pdi = &devices[i];
> +             res = name_check(pdi->name);
> +             if (res)
> +                     return res;
>               for (cpu = 0; setup_file(pdi, cpu); cpu++)
>                       ;
>       }
> 
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-btrace" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to