ra.nframes would be between 1 and 8 frames before anyway. The
8 is wrong though, since the app might just be asking for
1 block. I have changed that when merging.
> -= 2 =-
>
> + int nr = ra.nframes > 8 ? 8 : ra.nframes;
>
> why are you adding another variable? If this is neccessary (glancing at
> the code, it doesn't seem to be, just needs to be refined a bit),
> shouldn't it be a static int? i'm guessing at least that gcc isn't going
> to like you declaring a new int in the middle of things...
It isn't in the middle, read the C standard.
> -= 3 =-
>
> Yo forgot to modify the comment to "do between 1 and 300 frames at a
> time".
We're still doing between 1 and 8 frames in each pass, but
the app might have asked for 300 in total.
> though i must ask, why don't we pre-allocate cgc.buffer? i understand that
> there's the memory loss, but i wouldn't mind it much myself. i'm not sure
> how expensive kmalloc and kfree are, which is kind of important in
> deciding this.
How would that be possible? We setup the cgc command block
every time, there's no hidden state information.
-- * Jens Axboe <axboe@image.dk> * Linux CD-ROM Maintainer * http://www.kernel.dk- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/