|
Rockbox mail archiveSubject: RE: potential bug reportRE: 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 > firmware/drivers/ata.c::ata_read_sectors() > 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 mutexes. > 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? Exactly. > 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 level. I must say that you have done a great job reviewing our code. That is very valuable to us. Thanks a bunch! /Linus Received on 2002-06-12 Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy |