On Tue, Jun 21, 2011 at 05:42:24PM +0100, Toby Gray wrote:
> On 20/06/2011 22:35, Chris Frey wrote:
> > On Mon, Jun 20, 2011 at 11:26:12AM +0100, Toby Gray wrote:
> >>> 1) Your SetAltInterface() TODO message
> >>>
> > Sounds good to me.
>
> Fixed and tested on MacOSX 10.6.4 in e309b9847afc9a2ea86e on my github.
Merged!
> I've moved usbwrap to use a context which is currently just static
> within common.cc in b144ccb9199b4295db40.
Hmmm, I still don't like the Uninit() call in the destructor. Maybe
I'm just paranoid, but I can see cases where the application writer might
not ever want to call Uninit(), depending on his library dependencies.
At least for libusb 0.1 anyway, where the library is initialized only once.
> I had a go at creating a Barry::Context, but it turns out there's quite
> a lot to do. Every use of dout(), ddout() and eout() needs to have a
> context passed to it and that means that almost every Barry object has
> to hold a reference to the context object. Are you happy for this to be
> the case?
Not really. :-)
> There will also need to be some moving around of how some of the error
> logging works to simplify getting hold of the currently library context.
> For example Data::InputHexLine() uses dout, but having data objects all
> having references to the context just for debug logging in InputHexLine
> seems a little excessive.
That dout is just for debugging. It can be commented out if needed.
(But see my generic logging comments below)
InputHexLine isn't really used by any non-debug code either.
It's only for debugging these days.
> Or do you have an alternative suggestion of how dout(), ddout() and
> eout() can interoperate with a Barry context?
If we go the context route, and that's not definite yet, then I think
the main reference belongs in the Controller. It would look like this:
Context ctx;
Barry::Init(ctx);
Probe probe(ctx);
Controller con(probe.Get(1));
Something like that. The context would be in the ProbeResult passed to
the Controller, and Controller would have the main reference to it.
Controller is used in many places in the code anyway. It is sort of
the hub of USB communication, containing the device, interface, and
proberesult objects. The context could go here too.
I think it is important to have generic debug logging, though, without
context, because sometimes you just need to log an error, no matter what.
So I think it is ok to leave dout and friends as-is, for now, and not
include the logging stream in the context. In the future, we can
add context-oriented logging macros, that could take a controller object
as an argument, which would give the context.
What do you think?
> >> won't work with libusb 0.1 due to probing calling usb_scan_busses() to
> >> be called and therefore invalidating previous DeviceIDs.
> > This impression already exists, unfortunately. The user can copy around
> > ProbeResults that outlive Probe.
>
> That can be a problem with libusb 0.1 if the following sequence of
> events happens:
> 1. Program calls Probe()
> 2. Program copies a ProbeResult
> 3. Program calls ~Probe()
> 4. Program calls Probe()
> 5. Program attempts to use ProbeResult from 2.
>
> I think that step 5 will have undefined behaviour as libusb 0.1 will
> have freed/reused the memory pointed to by usb_device* when the second
> probe occurred at step 4.
I'm ok with this. I think this danger already exists in the Probe API
ever since it began. It's the second Probe() that is the problem, not
the ~Probe(), I believe. And that makes sense. Even iterators
can't outlive their container getting reorganized. ProbeResults are
even more stable than iterators here, since they can outlive Probe.
> > I like that idea a lot. :-) Actually, you could have an impl pointer in the
> > DeviceID class, probably even managed with shared_ptr<> internally, and the
> > DeviceID object could then be treated like POD, and copied straight.
> Done in b4c48ac76f0fc78b3fe0.
Merged!
> The old workaround for barrydesktop in fa10f865f61e73fbb89b was reverted
> in da1bd634f33658646728.
Merged!
Thanks very much!
- Chris
------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
_______________________________________________
Barry-devel mailing list
Barry-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/barry-devel
