From: Frank Gevaerts <frank_at_gevaerts.be>
Date: Tue, 2 Aug 2011 10:35:39 +0200

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.

> 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

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Received on 2011-08-02