From: Greg Haerr <greg_at_censoft.com>
Date: Wed, 12 Jun 2002 01:38:19 -0700

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).

All current cases of ata_read_sectors from
fat.c are called with count == 1 for the time being.

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... Very
cool low-level code, BTW.

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?

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)



Regards,

Greg
Received on 2002-06-12