Rockbox mail archiveSubject: Re: GSoC/Buflib: Weeky report #5
Re: GSoC/Buflib: Weeky report #5
From: Jonathan Gordon <jdgordy_at_gmail.com>
Date: Tue, 2 Aug 2011 23:45:45 +1000
On 2 August 2011 18:35, Frank Gevaerts <frank_at_gevaerts.be> wrote:
> On Tue, Aug 02, 2011 at 10:11:43AM +1000, Jonathan Gordon wrote:
>> On 2 August 2011 02:56, Thomas Martitz <kugel_at_rockbox.org> wrote:
>> > Hi folks,
>> > as I mentioned, I was very busy with exams for the past weeks. I finished
>> > them off last week (quite successfully too), so now I can concentrate on the
>> > GSoC project again.
>> > There's not a lot left actually. There are two patches pending:
>> > FS#12159 - GSoC/Buflib: Remove direct audiobuf accesses
>> > FS#12186 - GSoC/Buflib: Put extended buflib into core
>> > I intend to commit the first one quite soon. So this mail is also a request
>> > for testing this one out.
>> > The latter is not quite ready, but will be very soon (before the next
>> > weekend I hope).
>> > After that there's basically compaction enablement and regression testing
>> > left.
>> > Best regards.
>> The last patch on FS#12186 is from july 10? That is the most up to date version?
> It's the most up to date version on the tracker. Don't forget that
> Thomas has been away a few weeks for exams.
> It's also interestingly not the patch that he wants to commit now.
Reviewing an out of date patch is pretty pointless then!
>> Going by last nights logs it still looks like you are not handling the
>> important use case where a file needs to be loaded into a handle? Did
>> I miss discussion or is that still correct? If it requires a
>> intermediary buffer then what's the point?
> I think you misunderstood the discussion.
> Details aren't entirely final yet, but the move callback will be allowed to
> refuse moving. If actual implementation shows that for some cases this
> is *too* awkward and locking functions would be better, the scheme might
> be changed and such locking functions *might* be used introduced
> The "copy" discussion last night was about a case where the data to save
> is small enough to fit on the stack, which means that copy/save is just
> easier for that particular case. If you re-read the logs, you'll see
> that there was also a discussion about how things would be implemented
> for dircache (including a proposed patch, although I think one really
> needs to understand dircache to review that one), which would handle the
> situation by refusing to move during crititcal periods.
Ah ok, fine.
Received on 2011-08-02