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
> instead.
>
> 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.
>
> Frank
>

Ah ok, fine.
Received on 2011-08-02