Re: [Libusbx-devel] [PATCH/RFC] logging timestamps
Hi, On 05/03/2012 12:19 AM, Pete Batard wrote: > If we're going to have a bugfix release by the end of the week, I wouldn't > mind also having at least one useful new feature besides the fix. > > Timestamped logging looks like a good candidate, but we may want to improve > on Peter's implementation. As indicated, I wouldn't mind having a thread ID, > and I'm also not sure about setting the time origin to the very first log > message, as currently done. If the user plans to monitor multiple logs, it > may be useful to have the origin coincide with a global system event (eg. > boot) or some epoch, rather than something arbitrary. > > On the other hand, it seems that most usb monitoring utilities (usbmon as > well as Microsoft's NetMon) use their own origins and don't bother much about > sync with other apps (Usbmon also seems to use a 32 bit microsecond counter, > that loops about once every hour), and I guess trying to provide a stamp > indexed on a global event that works across all platforms would add in > complexity. > > Right now, the attached would be my current improvement on Peter's proposal > for timestamped/tid-ed logging. > > The resulting log output would be something like this: > > [ 2.636405] [040c] libusbx: debug [libusb_close] > [ 2.636405] [040c] libusbx: debug [libusb_unref_device] destroy device 1.2 > [ 2.652005] [040c] libusbx: debug [libusb_exit] > [ 2.652005] [040c] libusbx: debug [libusb_exit] destroying default context > [ 2.652005] [040c] libusbx: debug [usbi_remove_pollfd] remove fd 3 > [ 2.652005] [03a0] libusbx: debug [windows_clock_gettime_threaded] timer > thread quitting > > For the timestamp (first field), I'm using the same formatting as a > (timestamped) Linux dmesg provides, with the same behaviour for extra spaces. > As for the thread ID (second field), it is an int on all platforms, so fixed > 32 bit should do. I'm not sure many platforms will run into large tids > though, so the padding zeroes may be an overkill. Looks good to me! > Also note that on POSIX, the tid is obtained through syscall(SYS_gettid). I > expect it to work everywhere, but I have only tested the call on Linux. I think we should get this tested on *BSD before shipping 1.0.11. Regards, Hans -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Hi, On 05/02/2012 12:33 PM, Pete Batard wrote: > On 2012.05.02 09:28, Hans de Goede wrote: >> The problem is that with usb device redirection we can have 1 device >> already redirected, and then the user asks to redirect another device >> to the virtual machine, so we install a driver for the other device, >> and then need to be able to use the other device without re-init > > I see. > > Still, installing a driver and expecting libusbx to be in a state to use > the device is pretty much akin to hotplug on Windows, as you are > transitioning from a device that didn't have a supported driver and thus > was inaccessible to libusbx as if it wasn't plugged in, to a device that > is now accessible with a supported driver, i.e. as if it had been > plugged in. Well you've hotplug and hotplug, what is expected by spice is that after it detects a hotplug itself (through platform dependent code) that it can then do a new libusb_get_device_list() call and the new device will be there. So we're not asking for true hotplug, just that when we ask to re-enumerate devices we get an updated device list. This is how things currently work on other platforms. > Given the choice, I'd rather work on kickstarting the libusbx 2.0 branch > and apply the hp patches I have in -pbatard, but it may take a while... TBH I'm not convinced that adding hotplug requires an ABI / API break, and if possible I would like to avoid that. I'm fine with having a devel and stable branch, but I would like to avoid declaring the devel branch a do whatever you want to the API/ABI area. What I propose is that whenever we are thinking about a feature which may need API breakage, we first design the API for that feature, without taking compatibility in mind, so we assume API breakage is ok for the initial design. And then we do an iteration where we try to see if we can make it fit with the current API, if we can -> hurrah. If we cannot then we've a good reason to start an API incompat branch. This is also the procedure I would like to follow with hotplug. Regards, Hans -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps
On Thu, May 3, 2012 at 3:44 PM, Hans de Goede wrote: > Looks good to me! > >> Also note that on POSIX, the tid is obtained through syscall(SYS_gettid). > I expect it to work everywhere, but I have only tested the call on Linux. > > I think we should get this tested on *BSD before shipping 1.0.11. > Integrated this in git and I should be able to carry out tests under OpenBSD and NetBSD. I have working OpenBSD 5 setups with proper desktop environment I can work well with (XFCE4 and/or Gnome 2).I will also try out the latest 5.1 release (just released on 1-May-2012 but it should be okay since I tried 5.1 snapshot recently. I do not have a nice working desktop environment under NetBSD 5.1.2 (latest release version) but I can still make do with the basic setups (Fluxbox or Openbox) and carry out some tests there. I will also try out NetBSD 6 Beta later. -- Xiaofan -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] windows_usb: Fixing deadlock in backend when submitting transfers.
On 02/05/12 22:58, Pete Batard wrote: > On 2012.05.02 17:33, Toby Gray wrote: > This could lead to one of two deadlocks: > > 1) If the transfer completes while usbi_fd_notification() is waiting for > the event lock and the callback attempts to resubmit the transfer. > So transfer completes and we get a handle_events() call that takes the > event lock before usbi_fd_notification() gets a chance to have it. > During this handle_events, callback resubmits the transfer and attempts > to get a lock on itransfer->lock which it cannot obtain. With that lock > already being held and only to be released after usbi_fd_notification() > completes, which won't happen unless usbi_fd_notification() first gets > access to the event lock, that's a deadlock situation alright. Ouch! > >> 2) If the transfer timeout is hit while usbi_fd_notification() is waiting >> for the event lock then the attempt to cancel the transfer will deadlock. > Fairly similar to the above. The first thing cancel_transfer() tries to > do is get a lock on itransfer->lock, and we have the same issue. > > > So first of all, thanks for highlighting this problem - unless I'm > mistaken, that definitely something we need to patch. Did you actually > experience that race condition in practice? I first saw the resubmit deadlock when running on a 800Mhz CPU. It took about 20 minutes of almost continuous bulk transfers between the host and the USB device before I saw it, so I think it's safe to say it's quite a rare situation. It was only when I started adding lots of logging around all the lock usage to libusbx and stepping through the code path in the debugger that I noticed the second deadlock when canceling timed out transfers. >> This patch fixes both of these deadlocks by having libusb_submit_transfer() >> only call usbi_fd_notification() after having released the transfer mutex. > On principle, this looks okay to me. > > Don't think we have much choice but to move the usbi_fd_notification() > calls that we had in the Windows backend until after the transfer lock > has been released to avoid the deadlock, however, the proposal is fairly > heavy impact, as it requires all backends to be patched. I think adding > an extra field to the struct usbi_transfer, that performs the same > function as your updated_fds, may be better, as it should reduce the > scope of the patch. I haven't tested it but I'm not currently seeing > much of an issue doing it that way --apart from the fact that we'll > duplicate a variable what would be better suited as a global. Still I > think if we can avoid the need to patch all backends, I don't think the > extra field will do much harm. Ok. I'll create a second version of my patch which does it this way and then send it to this list. Looking into it it seemed most sensible to just add another flag to the transfer flags; there is already at least one flag, USBI_TRANSFER_OS_HANDLES_TIMEOUT, which the backend uses to communicate some OS specific information. I'm happy to change it to an entirely new member if that's a better choice than polluting the flags. Regards, Toby -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] [PATCH/RFC v2] windows_usb: Fixing deadlock in backend when submitting transfers.
Without this change the Windows backend needed to call usbi_fd_notification()
from within the backend's submit_transfer. This could cause deadlock
when attempting to lock the event lock if another thread was processing
events on the just-submitted transfer.
The deadlock comes about as the thread calling libusb_submit_transfer acquires
the transfer mutex before trying to acquire the event lock; this is the other
order of lock acquisition from an event thread handling activity on the just
submitted transfer. This could lead to one of two deadlocks:
1) If the transfer completes while usbi_fd_notification() is waiting for
the event lock and the callback attempts to resubmit the transfer.
2) If the transfer timeout is hit while usbi_fd_notification() is waiting
for the event lock then the attempt to cancel the transfer will deadlock.
This patch fixes both of these deadlocks by having libusb_submit_transfer()
only call usbi_fd_notification() after having released the transfer mutex.
Signed-off-by: Toby Gray
---
libusb/io.c |4
libusb/libusbi.h|3 +++
libusb/os/windows_usb.c |6 +++---
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/libusb/io.c b/libusb/io.c
index d7fae7e..ab32e70 100644
--- a/libusb/io.c
+++ b/libusb/io.c
@@ -1292,6 +1292,7 @@ int API_EXPORTED libusb_submit_transfer(struct
libusb_transfer *transfer)
LIBUSB_TRANSFER_TO_USBI_TRANSFER(transfer);
int r;
int first;
+ int updated_fds;
usbi_mutex_lock(&itransfer->lock);
itransfer->transferred = 0;
@@ -1325,7 +1326,10 @@ int API_EXPORTED libusb_submit_transfer(struct
libusb_transfer *transfer)
#endif
out:
+ updated_fds = (itransfer->flags & USBI_TRANSFER_UPDATED_FDS);
usbi_mutex_unlock(&itransfer->lock);
+ if (updated_fds)
+ usbi_fd_notification(ctx);
return r;
}
diff --git a/libusb/libusbi.h b/libusb/libusbi.h
index c3d2158..0aa6bf9 100644
--- a/libusb/libusbi.h
+++ b/libusb/libusbi.h
@@ -347,6 +347,9 @@ enum usbi_transfer_flags {
/* Operation on the transfer failed because the device disappeared */
USBI_TRANSFER_DEVICE_DISAPPEARED = 1 << 3,
+
+ /* Set by backend submit_transfer() if the fds in use have been updated
*/
+ USBI_TRANSFER_UPDATED_FDS = 1 << 4,
};
#define USBI_TRANSFER_TO_LIBUSB_TRANSFER(transfer) \
diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
index 1957964..f29f84c 100644
--- a/libusb/os/windows_usb.c
+++ b/libusb/os/windows_usb.c
@@ -1770,7 +1770,7 @@ static int submit_bulk_transfer(struct usbi_transfer
*itransfer)
usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd,
(short)(IS_XFERIN(transfer) ? POLLIN : POLLOUT));
- usbi_fd_notification(ctx);
+ itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
return LIBUSB_SUCCESS;
}
@@ -1790,7 +1790,7 @@ static int submit_iso_transfer(struct usbi_transfer
*itransfer)
usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd,
(short)(IS_XFERIN(transfer) ? POLLIN : POLLOUT));
- usbi_fd_notification(ctx);
+ itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
return LIBUSB_SUCCESS;
}
@@ -1809,7 +1809,7 @@ static int submit_control_transfer(struct usbi_transfer
*itransfer)
usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd, POLLIN);
- usbi_fd_notification(ctx);
+ itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
return LIBUSB_SUCCESS;
}
--
1.7.8.msysgit.0
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
On 2012.05.03 08:55, Hans de Goede wrote: > Well you've hotplug and hotplug, what is expected by spice is that after > it detects a hotplug itself (through platform dependent code) that it can > then do a new libusb_get_device_list() call and the new device will be > there. Which will happen when we have hotplug in libusb, as driver installation will generate a system hotplug event which will ensure that libusb_get_device_list() returns an up to date / real-time view of the devices available to libusb => this patch shouldn't be needed. > So we're not asking for true hotplug, just that when we ask to > re-enumerate devices we get an updated device list. I understand that. This doesn't detract from the fact that your requirement is meant to be handled by hotplug, as the installation of a driver or the plugging in of a new device are pretty much the same thing on Windows, as far as libusbx is concerned. Your solution would duplicate something that we're going to solve (in a different manner) when hotplug is in, and in general, duplicating solutions, or integrating a solution that we know will be removed later on, seems kind of a wasted effort. > This is how things > currently work on other platforms. Yes. And if you want, you should be able to get the same if you use the hp branch from -pbatard, without the need to apply your patch (though the branch probably needs some update and I'm trying to find the time to update it...). So I could state that this is also how things work on Windows. The only problem is that while the solution that should avoid your issue has been available for about 18 months now, it still hasn't been reviewed and integrated, and this is detrimental for all libusbx users. So that's what I would like us to work towards. I'd rather see time spent on a hotplug solution that solves your and other people's problems & requirements, than a patch that just solves your problem. This will of course take longer, but it should also be a lot more beneficial for everyone. >> Given the choice, I'd rather work on kickstarting the libusbx 2.0 branch >> and apply the hp patches I have in -pbatard, but it may take a while... > > TBH I'm not convinced that adding hotplug requires an ABI / API break, The hp branch begs to differ. We do have an hp proposal that doesn't require an API/ABI break and it was very much designed that way. We will of course add to the API, but so far I don't remember having identified anything that requires an API break. Now, we also do have a separate issue with cross platform event handling, that we also need to solve, and that is likely to require an API break. But that's a library-wide issue. Since hotplug would benefit from cross-platform event-handling, maybe that's the reason you consider that hp will require an API break, but the truth is that, hp or no hp, we'll need upgrade our event handling regardless, so it's not directly related. > and if possible I would like to avoid that. Same here. How about we look into a proposal then and see whether we think we can make it work without breaking the API/ABI? > I'm fine with having a > devel and stable branch, but I would like to avoid declaring the devel > branch a do whatever you want to the API/ABI area. Commits to this branch will be subject to the same review process as mainline, and it is meant to provide an upgrade path from 1.0, so I don't exactly see how it's meant to be seen as a "do whatever you want" branch. > What I propose is that whenever we are thinking about a feature which > may need API breakage, we first design the API for that feature, without > taking compatibility in mind, so we assume API breakage is ok for the > initial design. And then we do an iteration where we try to see if we > can make it fit with the current API, if we can -> hurrah. If we cannot > then we've a good reason to start an API incompat branch. I'm fine with that. > This is also the procedure I would like to follow with hotplug. The current hp proposal doesn't break the API. As far as I could see, Nokia (who are the originators of it) very much followed your proposal of not unnecessarily breaking the API. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps
On 2012.05.03 10:36, Xiaofan Chen wrote: > On Thu, May 3, 2012 at 3:44 PM, Hans de Goede wrote: >> I think we should get this tested on *BSD before shipping 1.0.11. Agreed. In case you wonder, I still plan to have an RC for 1.0.11. > Integrated this in git and I should be able to carry out tests under > OpenBSD and NetBSD. Thanks. That's much appreciated! Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Hi, On 05/03/2012 12:40 PM, Pete Batard wrote: > On 2012.05.03 08:55, Hans de Goede wrote: >> Well you've hotplug and hotplug, what is expected by spice is that after >> it detects a hotplug itself (through platform dependent code) that it can >> then do a new libusb_get_device_list() call and the new device will be >> there. > > Which will happen when we have hotplug in libusb, as driver installation > will generate a system hotplug event which will ensure that > libusb_get_device_list() returns an up to date / real-time view of the > devices available to libusb => this patch shouldn't be needed. I understand that hotplug will give us what we want, and we would love to switch to libusb hotplug rather then having our own platform dependent code to detect device addition / removal. >> So we're not asking for true hotplug, just that when we ask to >> re-enumerate devices we get an updated device list. > > I understand that. This doesn't detract from the fact that your > requirement is meant to be handled by hotplug, as the installation of a > driver or the plugging in of a new device are pretty much the same thing > on Windows, as far as libusbx is concerned. Your solution would > duplicate something that we're going to solve (in a different manner) > when hotplug is in, and in general, duplicating solutions, or > integrating a solution that we know will be removed later on, seems kind > of a wasted effort. IMHO the current libusbx-1.0.x behavior on windows is a bug and needs to be fixed, so this is not about needlessly adding new functionality duplicating effort, it is about fixing a bug. As said before re-enumeration though calling libusb_get_device_list() does work / include new devices on other platforms, and the docs say: "Returns a list of USB devices currently attached to the system. " Notice the *currently*, as in at the moment of the call... >> This is how things >> currently work on other platforms. > > Yes. And if you want, you should be able to get the same if you use the > hp branch from -pbatard, without the need to apply your patch (though > the branch probably needs some update and I'm trying to find the time to > update it...). So I could state that this is also how things work on > Windows. The only problem is that while the solution that should avoid > your issue has been available for about 18 months now, it still hasn't > been reviewed and integrated, and this is detrimental for all libusbx > users. So that's what I would like us to work towards. I'd rather see > time spent on a hotplug solution that solves your and other people's > problems& requirements, than a patch that just solves your problem. > This will of course take longer, but it should also be a lot more > beneficial for everyone. My problem with aiming for a hotplug solution here, is that a stable release of such a solution (ie of libusbx-2.0) will be a long time away. Where as a fix for just this issue can be done much quicker and added to libusb-1.0.12. > >>> Given the choice, I'd rather work on kickstarting the libusbx 2.0 branch >>> and apply the hp patches I have in -pbatard, but it may take a while... I understand, the problem is that we need a solution for this in a relative short amount of time and we're willing to do the work for that, so can you please review the proposed patch for fixing the enumeration behavior of the 1.0.x branch. And if the patch sucks we'll try to address your concerns. Hmm, reading further below I think I may have misunderstood things, if the plan is to add hotplug to libusbx-1.0.x, and do a release of that in a reasonable timeframe I can understand your POV even more then before. Still we have a need to get a fix out soonish as we want to make available a windows spice client with (limited, winusb only) usbredir support soon-ish. We can carry a patch to our windows libusbx copy for that if it is temporary, still a review would be appreciated in case we're breaking things without realizing it. >> TBH I'm not convinced that adding hotplug requires an ABI / API break, > > The hp branch begs to differ. We do have an hp proposal that doesn't > require an API/ABI break and it was very much designed that way. We will > of course add to the API, but so far I don't remember having identified > anything that requires an API break. Oh, good! > > Now, we also do have a separate issue with cross platform event > handling, that we also need to solve, and that is likely to require an > API break. But that's a library-wide issue. Since hotplug would benefit > from cross-platform event-handling, maybe that's the reason you consider > that hp will require an API break, but the truth is that, hp or no hp, > we'll need upgrade our event handling regardless, so it's not directly > related. > >> and if possible I would like to avoid that. > > Same here. How about we look into a proposal then and see whether we > think we can make it work without breaking the API/ABI? Definitely. You say you've a
Re: [Libusbx-devel] Microsoft's view on the perceived WinUSB limitations
On 2012.05.03 02:47, Xiaofan Chen wrote: > Also Tim's view on this topic in the OSR mailing list / forum. > http://www.osronline.com/showthread.cfm?link=223812 > +++ > One can also argue that this is a security measure. The USB spec > requires that the low byte of wIndex be set to the interface number when > the recipient is set to "interface". Devices that use that field for > other purposes are broken. > Yup, I saw it and I agree with Tim. The issue was that I thought Microsoft mandated the use of an arbitrary wIndex with an "interface" recipient when reading the WCID properties, and thus were breaking this recommendation. That's how this limitation was highlighted in the first place. As long as this isn't the case, and WinUSB only overrides wIndex for interface recipients, which it does (a request to a device recipient lets you use any wIndex you want), there's no problem. I think I'll remove this limitation from the Windows Banckend page, as it isn't really one. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
On 2012.05.03 11:55, Hans de Goede wrote: > IMHO the current libusbx-1.0.x behavior on windows is a bug and needs > to be fixed, IMHO, not having hotplug in libusb(x) is a major bug, rather than a just another very desirable feature, that should be fixed ASAP. In terms of priority, besides critical bugs that pop out and need an immediate fix, that would be on the top of my list. > so this is not about needlessly adding new functionality > duplicating effort, it is about fixing a bug. Yes, I agree. Except I see it part of a larger bug that also need to be fixed. > My problem with aiming for a hotplug solution here, is that a stable > release of such a solution (ie of libusbx-2.0) will be a long time away. 2.0 is a long time away, but a usable -devel may not. The plan is of course to have a -devel that, while experimental, is as stable as possible and that people can use in their apps. > Where as a fix for just this issue can be done much quicker and added > to libusb-1.0.12. As I said I currently sit on the fence with regards to this patch. Obviously, I would very much prefer having you guys use hotplug, as it would help us validate our implementation, which would benefit others. Also, considering that you will have to remove the patch and switch to a hotplug solution sooner or later, it might be worth ensuring you still have your requirements filled when that happens. But if not having something quick is a major issue, I don't have a major problem integrating it (though I haven't really reviewed it yet). > I understand, the problem is that we need a solution for this in a relative > short amount of time What are your constraints there? > Hmm, reading further below I think I may have misunderstood things, if the > plan is to add hotplug to libusbx-1.0.x, and do a release of that in > a reasonable timeframe I can understand your POV even more then before. Actually, that wasn't really my plan, but if there's a vote to try for hp in 1.0, I'm really all for it, as the proposal was designed for 1.0 anyway. I'd have no problem moving hp before libusb0/libusbk support and other things. > Still we have a need to get a fix out soonish as we want to make available > a windows spice client with (limited, winusb only) usbredir support > soon-ish. soonish = ? > We can carry a patch to our windows libusbx copy for that if it is > temporary, still a review would be appreciated in case we're breaking > things > without realizing it. We might as well have it in mainline if you guys use it, as it could benefit others. I'll see what I can do for review... Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC v2] windows_usb: Fixing deadlock in backend when submitting transfers.
On 2012.05.03 11:25, Toby Gray wrote:
> Without this change the Windows backend needed to call usbi_fd_notification()
> from within the backend's submit_transfer. This could cause deadlock
> when attempting to lock the event lock if another thread was processing
> events on the just-submitted transfer.
>
> The deadlock comes about as the thread calling libusb_submit_transfer acquires
> the transfer mutex before trying to acquire the event lock; this is the other
> order of lock acquisition from an event thread handling activity on the just
> submitted transfer. This could lead to one of two deadlocks:
>
> 1) If the transfer completes while usbi_fd_notification() is waiting for
> the event lock and the callback attempts to resubmit the transfer.
>
> 2) If the transfer timeout is hit while usbi_fd_notification() is waiting
> for the event lock then the attempt to cancel the transfer will deadlock.
>
> This patch fixes both of these deadlocks by having libusb_submit_transfer()
> only call usbi_fd_notification() after having released the transfer mutex.
Looks good to me. Thanks for sending the updated version and good call
on making sure we get a copy of the flags before we release the lock.
On 2012.05.03 11:28, Toby Gray wrote:
> Looking into it it seemed most sensible to just add another flag to
> the transfer flags; there is already at least one flag,
> USBI_TRANSFER_OS_HANDLES_TIMEOUT, which the backend uses to
> communicate some OS specific information. I'm happy to change it to
> an entirely new member if that's a better choice than polluting the
> flags.
Looks sensible to me too. Didn't realize we already had a bunch of flags
there - of course we want to extend on those while we can.
Unless there are comments, I'll integrate your patch later on today.
Thanks again,
/Pete
> Signed-off-by: Toby Gray
> ---
> libusb/io.c |4
> libusb/libusbi.h|3 +++
> libusb/os/windows_usb.c |6 +++---
> 3 files changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libusb/io.c b/libusb/io.c
> index d7fae7e..ab32e70 100644
> --- a/libusb/io.c
> +++ b/libusb/io.c
> @@ -1292,6 +1292,7 @@ int API_EXPORTED libusb_submit_transfer(struct
> libusb_transfer *transfer)
> LIBUSB_TRANSFER_TO_USBI_TRANSFER(transfer);
> int r;
> int first;
> + int updated_fds;
>
> usbi_mutex_lock(&itransfer->lock);
> itransfer->transferred = 0;
> @@ -1325,7 +1326,10 @@ int API_EXPORTED libusb_submit_transfer(struct
> libusb_transfer *transfer)
> #endif
>
> out:
> + updated_fds = (itransfer->flags& USBI_TRANSFER_UPDATED_FDS);
> usbi_mutex_unlock(&itransfer->lock);
> + if (updated_fds)
> + usbi_fd_notification(ctx);
> return r;
> }
>
> diff --git a/libusb/libusbi.h b/libusb/libusbi.h
> index c3d2158..0aa6bf9 100644
> --- a/libusb/libusbi.h
> +++ b/libusb/libusbi.h
> @@ -347,6 +347,9 @@ enum usbi_transfer_flags {
>
> /* Operation on the transfer failed because the device disappeared */
> USBI_TRANSFER_DEVICE_DISAPPEARED = 1<< 3,
> +
> + /* Set by backend submit_transfer() if the fds in use have been updated
> */
> + USBI_TRANSFER_UPDATED_FDS = 1<< 4,
> };
>
> #define USBI_TRANSFER_TO_LIBUSB_TRANSFER(transfer) \
> diff --git a/libusb/os/windows_usb.c b/libusb/os/windows_usb.c
> index 1957964..f29f84c 100644
> --- a/libusb/os/windows_usb.c
> +++ b/libusb/os/windows_usb.c
> @@ -1770,7 +1770,7 @@ static int submit_bulk_transfer(struct usbi_transfer
> *itransfer)
> usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd,
> (short)(IS_XFERIN(transfer) ? POLLIN : POLLOUT));
>
> - usbi_fd_notification(ctx);
> + itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
> return LIBUSB_SUCCESS;
> }
>
> @@ -1790,7 +1790,7 @@ static int submit_iso_transfer(struct usbi_transfer
> *itransfer)
> usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd,
> (short)(IS_XFERIN(transfer) ? POLLIN : POLLOUT));
>
> - usbi_fd_notification(ctx);
> + itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
> return LIBUSB_SUCCESS;
> }
>
> @@ -1809,7 +1809,7 @@ static int submit_control_transfer(struct usbi_transfer
> *itransfer)
>
> usbi_add_pollfd(ctx, transfer_priv->pollable_fd.fd, POLLIN);
>
> - usbi_fd_notification(ctx);
> + itransfer->flags |= USBI_TRANSFER_UPDATED_FDS;
> return LIBUSB_SUCCESS;
>
> }
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
libusbx-devel mailing list
libusbx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Hi, On 05/03/2012 01:13 PM, Pete Batard wrote: > On 2012.05.03 11:55, Hans de Goede wrote: >> IMHO the current libusbx-1.0.x behavior on windows is a bug and needs >> to be fixed, > > IMHO, not having hotplug in libusb(x) is a major bug, rather than a just > another very desirable feature, that should be fixed ASAP. In terms of > priority, besides critical bugs that pop out and need an immediate fix, > that would be on the top of my list. I agree it is an important missing feature, and that it is something which should have been added a long time ago. >> so this is not about needlessly adding new functionality >> duplicating effort, it is about fixing a bug. > > Yes, I agree. Except I see it part of a larger bug that also need to be > fixed. hehe >> My problem with aiming for a hotplug solution here, is that a stable >> release of such a solution (ie of libusbx-2.0) will be a long time away. > > 2.0 is a long time away, but a usable -devel may not. The plan is of > course to have a -devel that, while experimental, is as stable as > possible and that people can use in their apps. The problem is that we want to have it integrated into Fedora and also RHEL, so as stable as possible is not necessarily good enough. I know stable releases can and will have bugs too, but going with a devel release will be a hard thing to sell. >> Where as a fix for just this issue can be done much quicker and added >> to libusb-1.0.12. > > As I said I currently sit on the fence with regards to this patch. > > Obviously, I would very much prefer having you guys use hotplug, as it > would help us validate our implementation, which would benefit others. > Also, considering that you will have to remove the patch and switch to a > hotplug solution sooner or later, it might be worth ensuring you still > have your requirements filled when that happens. I've just discussed this with Uri and Arnon and we definitely want to drop our platform specific hacks for this and switch to libusbx hotplug support in the near future. So as soon as there is something testable you can count on us to try and convert spice to that and run various tests with it. And I've already learned the hardway that Spice's redir code is one of the more stressing users of libusb (as it needs to work with any random device), so you can count on it getting some good testing when we switch over :) > But if not having something quick is a major issue, I don't have a major > problem integrating it (though I haven't really reviewed it yet). > >> I understand, the problem is that we need a solution for this in a relative >> short amount of time > > What are your constraints there? We need a solution in say max a month from now. Note that even if you were to manage to do a stable release with hotplug support in that timeframe, we won't have the time to convert and revalidate all our code in that timeframe. So although such a release would also fix our issue with re-numeration, we won't be using the new functionality just yet. As said above we will switch to it asap, depending on the libusbx schedule I'm thinking / hoping of having spice use libusbx-hotplug for Fedora 18, so that is slightly more then 6 months from now for the official release. >> Hmm, reading further below I think I may have misunderstood things, if the >> plan is to add hotplug to libusbx-1.0.x, and do a release of that in >> a reasonable timeframe I can understand your POV even more then before. > > Actually, that wasn't really my plan, but if there's a vote to try for > hp in 1.0, I'm really all for it, as the proposal was designed for 1.0 > anyway. I'd have no problem moving hp before libusb0/libusbk support and > other things. I for one would really love to see hp in 1.0, libusb0/libusbk support is also quite important to us though, and also something we would really like to see in 1.0 >> Still we have a need to get a fix out soonish as we want to make available >> a windows spice client with (limited, winusb only) usbredir support >> soon-ish. > > soonish = ? As said max a month from now. >> We can carry a patch to our windows libusbx copy for that if it is >> temporary, still a review would be appreciated in case we're breaking >> things >> without realizing it. > > We might as well have it in mainline if you guys use it, as it could > benefit others. I'll see what I can do for review... Thanks! Regards, Hans -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] libusb_kernel_driver_active() and _detach() are racy
On Thu, 3 May 2012, Xiaofan Chen wrote: > Last time we have a long discussion here and there is no good > solution to the following ticket. > http://www.libusb.org/ticket/125 > libusb_kernel_driver_active() and _detach() are racy > "If the functionality is to be kept in the next API then let's do > something that isn't racy." > > Relevant discussion (long thread). > http://libusb.6.n5.nabble.com/Patch-libusb-os-linux-usbfs-c-Distingush-between-usbfs-and-other-kernel-mode-drivers-td3199947.html > > Any new thought on this topic? Is it even possible to do this > without changing the Linux kernel usbfs driver? I don't think so. At the very least, it would be necessary to change the USBDEVFS_DISCONNECT ioctl to make it avoid doing anything if the current driver is usbfs. A better approach would be to allow the user to specify a driver name, and have USBDEVFS_DISCONNECT do nothing if the current driver isn't the one specified. Alan Stern -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Microsoft's view on the perceived WinUSB limitations
Hans Petter Selasky wrote: > In the answers from the Microsoft guy, there were some arguments about > security. Many kind of device drivers could have been made more secure by > moving out of the kernel, for example webcam drivers, which is a class of > devices which are especially using a lot of isochronous endpoints. The use > case is there for sure, but probably nobody saw it. I have long argued that code should never be in the kernel unless it absolutely MUST be in the kernel, but isochronous drivers almost always have performance and latency issues. The primary disadvantage of moving drivers to user-mode is that latency goes up and throughput goes down. Microsoft quotes a 10% performance penalty. There are many classes where that doesn't matter, but webcam drivers aren't one of them. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] Microsoft's view on the perceived WinUSB limitations
On Thursday 03 May 2012 19:02:35 Tim Roberts wrote: > Hans Petter Selasky wrote: > > In the answers from the Microsoft guy, there were some arguments about > > security. Many kind of device drivers could have been made more secure by > > moving out of the kernel, for example webcam drivers, which is a class of > > devices which are especially using a lot of isochronous endpoints. The > > use case is there for sure, but probably nobody saw it. > > I have long argued that code should never be in the kernel unless it > absolutely MUST be in the kernel, but isochronous drivers almost always > have performance and latency issues. The primary disadvantage of moving > drivers to user-mode is that latency goes up and throughput goes down. > Microsoft quotes a 10% performance penalty. There are many classes > where that doesn't matter, but webcam drivers aren't one of them. Hi, Being the author of webcamd I don't fully agree about that. User-land overhead is minimal. When pictures are encoded in JPEG or H.264 format, most of the overhead will be in the application and not in the driver! Reference: http://www.freshports.org/multimedia/webcamd/ --HPS -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
[Libusbx-devel] USB port number
Hello I am new to libusbx and I have one basic question I would like to determine to which usb port particular device is attached. I can see this information with UsbView from Microsoft or UsbDeview program. I have tested lisdev.c program from examples directory however function libusb_get_device_address() does not provide this information. I tested it and it returns the same number for my usb key regardless of the port I am plugging it in. libusb_get_bus_number() works nice though. I guess I would need something like libusb_get_port_number(dev), however this function does not exist. Are there some other ways I could determine port ? Would it be possible to add a function for port determination in API ? I am using windows 7. Best regards, Janko Kolar -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC v2] windows_usb: Fixing deadlock in backend when submitting transfers.
Patch has now been pushed. I also pushed a fix for xusb, as a result of the WinUSB limitations discussion. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v2
After testing on OS X, and finding the syscall didn't work, it seems
that each POSIX platform has its own way of getting a thread ID.
This v2 of the patch should ensure that all the libusbx supported
platforms return a valid thread ID. It was tested for OS X and Linux,
but not for BSD.
Regards,
/Pete
>From 9fc20bc7ecd23861520d82419beb5646aa44bfe5 Mon Sep 17 00:00:00 2001
From: Peter Stuge
Date: Wed, 2 May 2012 17:04:00 +
Subject: [PATCH] Core: Add a timestamping and thread ID to logging
---
configure.ac|1 +
libusb/core.c | 67 ++-
libusb/libusbi.h| 12
libusb/os/threads_posix.c | 26
libusb/os/threads_posix.h |2 +
libusb/os/threads_windows.c |4 ++
libusb/os/threads_windows.h |2 +
7 files changed, 114 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index db5c534..792035f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -210,6 +210,7 @@ AM_CONDITIONAL([HAVE_SIGACTION], [test "x$have_sigaction" =
"xyes"])
# headers not available on all platforms but required on others
AC_CHECK_HEADERS([sys/time.h])
+AC_CHECK_FUNCS(gettimeofday)
AM_CFLAGS="-std=gnu99 -Wall -Wundef -Wunused -Wstrict-prototypes
-Werror-implicit-function-declaration $nopointersign_cflags -Wshadow"
diff --git a/libusb/core.c b/libusb/core.c
index 1a95dd4..e4f83d8 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -27,6 +27,10 @@
#include
#include
+#ifdef HAVE_SYS_TIME_H
+#include
+#endif
+
#include "libusbi.h"
#if defined(OS_LINUX)
@@ -1665,11 +1669,59 @@ int API_EXPORTED libusb_has_capability(uint32_t
capability)
return 0;
}
+/* this is defined in libusbi.h if needed */
+#ifdef LIBUSB_GETTIMEOFDAY_WIN32
+/*
+ * gettimeofday
+ * Implementation according to:
+ * The Open Group Base Specifications Issue 6
+ * IEEE Std 1003.1, 2004 Edition
+ */
+
+/*
+ * THIS SOFTWARE IS NOT COPYRIGHTED
+ *
+ * This source code is offered for use in the public domain. You may
+ * use, modify or distribute it freely.
+ *
+ * This code is distributed in the hope that it will be useful but
+ * WITHOUT ANY WARRANTY. ALL WARRANTIES, EXPRESS OR IMPLIED ARE HEREBY
+ * DISCLAIMED. This includes but is not limited to warranties of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ * Contributed by:
+ * Danny Smith
+ */
+
+/* Offset between 1/1/1601 and 1/1/1970 in 100 nanosec units */
+#define _W32_FT_OFFSET (1164447360)
+
+int usbi_gettimeofday(struct timeval *tp, void *tzp)
+ {
+ union {
+unsigned __int64 ns100; /*time since 1 Jan 1601 in 100ns units */
+FILETIME ft;
+ } _now;
+
+ if(tp)
+{
+ GetSystemTimeAsFileTime (&_now.ft);
+ tp->tv_usec=(long)((_now.ns100 / 10) % 100 );
+ tp->tv_sec= (long)((_now.ns100 - _W32_FT_OFFSET) / 1000);
+}
+ /* Always return 0 as per Open Group Base Specifications Issue 6.
+ Do not set errno on error. */
+ return 0;
+}
+#endif
+
void usbi_log_v(struct libusb_context *ctx, enum usbi_log_level level,
const char *function, const char *format, va_list args)
{
FILE *stream = stdout;
const char *prefix;
+ struct timeval now;
+ static struct timeval first = { 0, 0 };
#ifndef ENABLE_DEBUG_LOGGING
USBI_GET_CONTEXT(ctx);
@@ -1681,6 +1733,18 @@ void usbi_log_v(struct libusb_context *ctx, enum
usbi_log_level level,
return;
#endif
+ usbi_gettimeofday(&now, NULL);
+ if (!first.tv_sec) {
+ first.tv_sec = now.tv_sec;
+ first.tv_usec = now.tv_usec;
+ }
+ if (now.tv_usec < first.tv_usec) {
+ now.tv_sec--;
+ now.tv_usec += 100;
+ }
+ now.tv_sec -= first.tv_sec;
+ now.tv_usec -= first.tv_usec;
+
switch (level) {
case LOG_LEVEL_INFO:
prefix = "info";
@@ -1703,7 +1767,8 @@ void usbi_log_v(struct libusb_context *ctx, enum
usbi_log_level level,
break;
}
- fprintf(stream, "libusb:%s [%s] ", prefix, function);
+ fprintf(stream, "[%5d.%06d] [%08x] libusbx: %s [%s] ",
+ (int)now.tv_sec, (int)now.tv_usec, usbi_get_tid(), prefix,
function);
vfprintf(stream, format, args);
diff --git a/libusb/libusbi.h b/libusb/libusbi.h
index 0aa6bf9..b8abab5 100644
--- a/libusb/libusbi.h
+++ b/libusb/libusbi.h
@@ -209,6 +209,18 @@ static inline void usbi_dbg(const char *format, ...)
#include
#endif
+#if defined(OS_WINDOWS) && !defined(__GCC__)
+#undef HAVE_GETTIMEOFDAY
+int usbi_gettimeofday(struct timeval *tp, void *tzp);
+#define LIBUSB_GETTIMEOFDAY_WIN32
+#define HAVE_USBI_GETTIMEOFDAY
+#else
+#ifdef HAVE_GETTIMEOFDAY
+#define usbi_gettimeofday(tv, tz) gettimeofday((tv), (tz))
+#define HAVE_USBI_GETTIMEOFDAY
+#endif
+#endif
+
extern struct libusb_context *usbi_default_context;
struct libusb_context {
diff --git a/libusb/os/thread
Re: [Libusbx-devel] USB port number
Hi Janko, On 2012.05.03 13:23, Janko Kolar wrote: > I would like to determine to which usb port particular device is attached. > I can see this information with UsbView from Microsoft or UsbDeview program. This is the topology call, which we plan to implement in the v1.0.12 release of libusbx - hopefully to be released in about a month. If you can't wait, you'll find that you can already test it in libusbx-pbatard [1]. Check out the libusb_get_port_number() call [2]. Regards, /Pete [1] http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx-pbatard;a=summary [2] http://libusbx.git.sourceforge.net/git/gitweb.cgi?p=libusbx/libusbx-pbatard;a=blob;f=libusb/libusb.h;#l966 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v2
On Thu, 3 May 2012 23:20:09 +0100, Pete Batard said: >+#elif defined(__APPLE__) >+ ret = mach_thread_self(); >+ mach_port_deallocate(mach_task_self(), ret); Perhaps I missed an earlier discussion, but why drop to the mach level? Wouldn't pthread_self() be more portable? -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
On 2012.05.03 14:22, Hans de Goede wrote: >> What are your constraints there? > > We need a solution in say max a month from now. Realistically, I don't think we can have an hp solution by then, so that means we'll probably need to apply the patch. Regards, /Pete -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [PATCH/RFC] logging timestamps v2
On 2012.05.03 23:27, Sean McBride wrote: > On Thu, 3 May 2012 23:20:09 +0100, Pete Batard said: > >> +#elif defined(__APPLE__) >> +ret = mach_thread_self(); >> +mach_port_deallocate(mach_task_self(), ret); > > Perhaps I missed an earlier discussion, but why drop to the mach level? > Wouldn't pthread_self() be more portable? The problem with pthread_self() is it returns a pthread_t, which, from what I could see, is not guaranteed to be an integer (can be an opaque struct [1]). Since we want to display it, we need an integer value. Regards, /Pete [1] http://stackoverflow.com/questions/1759794/how-to-print-pthread-t -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
Re: [Libusbx-devel] [RFC PATCH] windows_usb: get_device_list: if the backend api changed, use the new api
Hans de Goede wrote: > what is expected by spice is that after it detects a hotplug itself > (through platform dependent code) that it can then do a new > libusb_get_device_list() call and the new device will be there. What hotplug events are received? Ie. when a device driver changes, does the same device (as exposed by the Windows backend) go away and come back, or will the previous libusb_device actually have disappeared during the driver change? //Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ libusbx-devel mailing list libusbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libusbx-devel
