Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: RE: potential bug report
From: Nielsen Linus (ext) (Linus.Nielsen_at_elema.siemens.se)
Date: 2002-06-12


> 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



Page was last modified "Jan 10 2012" The Rockbox Crew
aaa