[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [PATCH 0/5] Integration of libcdio-pbatard changes

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] [PATCH 0/5] Integration of libcdio-pbatard changes
Date: Fri, 10 Feb 2012 23:39:17 -0500

On Fri, Feb 10, 2012 at 2:34 PM, Pete Batard <address@hidden> wrote:

> With libcdio-pbatard now complete in terms of fixes and features, I am in
> a position to push for the changes to be integrated into mainline at last.


> As previously indicated I have created a new pbatard-integration branch
> dedicated where I will push a few commits at a time, with a copy of those
> also being sent to the mailing list, and will wait for integration before
> pushing some more.

This is very kind and considerate.

> While I was at it, you will see that I added a MSVC project for
> cd-paranoia in -pbatard, mostly because I was observing a crash there
> during testing, that was a lot easier to troubleshoot using MSVC. I have
> also applied fixes for tests that I found problematic, so that they now all
> work properly, including with MinGW (the only one that fails on MinGW now
> is rock-ridge, which is purely due to symbolic links not being available
> for extracted data on Window).

I can try to address that.

> The way I'd like to proceed, which is also how I am planning to submit
> patches, is to have the fixes and extract.c sample
> integrated first, since not having them will hinder testing, then get the
> cumbersome but minor stuff out of the way (source headers improvements),
> then ensure that we have a set of tests that work on all platforms (there
> are a few things to address there) before finally going to the main course
> with core file patches.
> The 5 patches from this first salvo should be fairly independent and will
> stop short of the testing fixes.

I will try to look at these this soon. Again, thanks.

> Regards,
> /Pete
> PS: On a side note I'm quite pleased to have stuck with libcdio in my app
> and not switch to using 7-zip or something else, as tests shown that my
> application is about twice as fast on UDF extraction as the competition
> [1]. Of course, this is in great part due to the default Windows buffering
> mechanisms, since I haven't optimized anything with regards to extraction,
> and everything is very much read one block at time, but it also indicates
> that the libcdio code is not slowing us down in any way. Good job!
> [1] -> "(1) Speed comparison between Rufus and
> other applications"

Pretty impressive.

I too am glad you stuck with libcdio; we get the benefit of your
improvements. Thanks again.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]