Rockbox mail archiveSubject: RE: potential bug report
RE: potential bug report
From: Nielsen Linus (ext) <"Nielsen>
Date: Wed, 12 Jun 2002 11:24:22 +0200
> A quick review of the source shows that,
> although not a bug yet, the code in
> won't work if the count parameter is ever
> called with a value != 1. This is because the
> 'buf' value in the inner for loop is never incremented
> by the size of a disk sector (512).
Good catch! I'll fix that.
> BTW, I'm trying to understand exactly how many threads
> are running in the current version. Is it just the mpeg_thread,
> or is there a seperate UI/button thread? I ask because
> the ATA disk routines have mutex sections, and was
> wondering whether the entire disk subsystem was built
> to work using open "files" from multiple threads...
Yes, there are several threads that do disk I/O, so the ATA code needs those
> Very cool low-level code, BTW.
Thank you. We try our best.
> In the kernel.c mutex_lock function, there's no STI/CLI
> pair around the mutex, is this because there's no
> preemptive scheduling?
> I see that the queue_post routines have it, and I assume
> that's because those routines can be called from a
> bottom-half interrupt routine (which aren't scheduled,
> just interrupt-driven?
You know your stuff. And you are absolutely right. Posting to queues are
done in interrupts, for example the button driver.
> I haven't seen yet what gcc emits for SH1, but for
> some systems, ++m->count is much faster than
> m->count++. (same for decrement)
Interesting. I haven't tried. Still, we're generally not optimizing on that
I must say that you have done a great job reviewing our code. That is very
valuable to us. Thanks a bunch!
Received on 2002-06-12