Rockbox mail archive

• Next message: Greg Haerr: "win32 make"
• Previous message: Björn Stenberg: "Re: potential bug report"
• Maybe in reply to: Greg Haerr: "potential bug report"
• Next in thread: Nielsen Linus (ext): "RE: potential bug report"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

> 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

• Next message: Greg Haerr: "win32 make"
• Previous message: Björn Stenberg: "Re: potential bug report"
• Maybe in reply to: Greg Haerr: "potential bug report"
• Next in thread: Nielsen Linus (ext): "RE: potential bug report"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]