On Sun, May 6, 2012 at 7:35 AM, Pete Batard <p...@akeo.ie> wrote: > I just tested OpenBSD, and it seems that each *BSD has its own method to get > a thread ID, with OpenBSD apparently having none ([1] "OpenBSD: not possible > here, there is no way to get a TID") up to recently ([2] "The ps(1) program > gains the tid formatting keyword. In conjunction with the -H option, thread > ID is now included"). Thus the previous proposal, that used the FreeBSD way > of getting a Thread ID, doesn't work. > > This seems to be confirmed with the fact that the WINE implementation > doesn't have any other BSDs besides FreeBSD (which we don't support) in its > cross-plaform thread ID implementation [3]. > > With BSD support becoming a headache, and no official maintainer for the > *BSD backends to help us out, along with the need to go to bugfix release > soon, I propose dropping thread IDs for OpenBSD/NetBSD for the time being, > and just return -1 there.
I think that is fair. I will forward this to the OpenBSD developer to see if he has some input. > Now, if you think it's important to have a BSD tid implementation ASAP, > you're of course very much invited to propose a patch, but please don't > expect someone else will spend their limited time doing that work, or argue > that the provision of thread IDs for Linux, Windows and OS X should be > delayed because of *BSD, whereas, even without *BSD, at least 95% of our > userbase is likely to benefit. > > Thus, the attached is what I would currently go to release with, pending the > possibility to identify whether we can/need to make the OS X thread ID > coincide with X Code debug thread IDs. A minor thing, email program add a ">" in front of the first "From" so that "git am" actually failed. Remove the ">" from your attached patch solved the problem. > > Please note that I have also included a change that adds a header with a > legend at the beginning of the log, which is very much RFC, i.e., I think > it'll be helpful in case people wonder what the second column is for, as > well as for making sure that the beginning on libusbx operations in a log > that contains more than libusbx output is clearly highlighted, but if there > are strong opinions against that header I don't have a problem removing it. > I also reduced the default number of spaces before the timestamp, with the > resulting output currently being as follows: > > [timestamp] [threadID] facility level [function call] <message> > -------------------------------------------------------------------------------- > [ 0.000000] [00000b04] libusbx: debug [libusb_init] > [ 0.010000] [00000b04] libusbx: debug [init_polling] Will use CancelIoEx for > I/O cancellation > [ 0.022500] [00000b04] libusbx: debug [htab_create] using 1021 entries hash > table > [ 0.025000] [00000b04] libusbx: debug [usbi_add_pollfd] add fd 3 events 1 > [ 0.027500] [00000b04] libusbx: debug [libusb_init] created default context > [ 0.030000] [00000b04] libusbx: debug [libusb_get_device_list] > [ 0.022500] [000010e4] libusbx: debug [windows_clock_gettime_threaded] hires > timer available (Frequency: 2083369 Hz) This is what I have under Mac OS X Lion. mymacmini:examples xiaofanc$ ./listdevs [timestamp] [threadID] facility level [function call] <message> -------------------------------------------------------------------------------- [ 0.000000] [00000e07] libusbx: debug [libusb_init] [ 0.000122] [00001707] libusbx: info [event_thread_main] creating hotplug event source [ 0.000712] [00001707] libusbx: info [event_thread_main] thread ready to receive events [ 0.000780] [00000e07] libusbx: debug [usbi_add_pollfd] add fd 4 events 1 [ 0.000797] [00000e07] libusbx: debug [libusb_init] created default context [ 0.000811] [00000e07] libusbx: debug [libusb_get_device_list] [ 0.003081] [00000e07] libusbx: info [process_new_device] allocating new device for location 0xfa000000 [ 0.003122] [00000e07] libusbx: debug [darwin_cache_device_descriptor] device descriptor: [ 0.003132] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDescriptorType: 0x01 [ 0.003138] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bcdUSB: 0x0200 [ 0.003146] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceClass: 0x09 [ 0.003152] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00 [ 0.003158] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x01 [ 0.003165] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40 [ 0.003171] [00000e07] libusbx: debug [darwin_cache_device_descriptor] idVendor: 0x05ac [ 0.003177] [00000e07] libusbx: debug [darwin_cache_device_descriptor] idProduct: 0x8006 [ 0.003184] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bcdDevice: 0x0200 [ 0.003190] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iManufacturer: 0x02 [ 0.003196] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iProduct: 0x01 [ 0.003202] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iSerialNumber: 0x00 [ 0.003209] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01 [ 0.003240] [00000e07] libusbx: info [darwin_check_configuration] active config: 1, first config: 1 [ 0.003251] [00000e07] libusbx: info [process_new_device] found device with address 1 at 001-05ac-8006-09-00 [ 0.003577] [00000e07] libusbx: info [process_new_device] allocating new device for location 0xfa100000 [ 0.003708] [00000e07] libusbx: debug [darwin_cache_device_descriptor] device descriptor: [ 0.003725] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDescriptorType: 0x01 [ 0.003736] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bcdUSB: 0x0200 [ 0.003746] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceClass: 0x09 [ 0.003756] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceSubClass: 0x00 [ 0.003766] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bDeviceProtocol: 0x02 [ 0.003776] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bMaxPacketSize0: 0x40 [ 0.003785] [00000e07] libusbx: debug [darwin_cache_device_descriptor] idVendor: 0x0424 [ 0.003795] [00000e07] libusbx: debug [darwin_cache_device_descriptor] idProduct: 0x2513 [ 0.003812] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bcdDevice: 0x0bb3 [ 0.003821] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iManufacturer: 0x00 [ 0.003830] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iProduct: 0x00 [ 0.003839] [00000e07] libusbx: debug [darwin_cache_device_descriptor] iSerialNumber: 0x00 [ 0.003849] [00000e07] libusbx: debug [darwin_cache_device_descriptor] bNumConfigurations: 0x01 [ 0.003883] [00000e07] libusbx: info [darwin_check_configuration] active config: 1, first config: 1 [ 0.003895] [00000e07] libusbx: info [process_new_device] found device with address 2 at 002-0424-2513-09-00 [ 0.004262] [00000e07] libusbx: info [process_new_device] allocating new device for location 0xfa110000 [ 0.004445] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe000404f. sleeping for 30 ms before trying again [ 0.035206] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe00002ed. sleeping for 30 ms before trying again [ 0.066813] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe000404f. sleeping for 30 ms before trying again [ 0.097813] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe00002ed. sleeping for 30 ms before trying again [ 0.129163] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe000404f. sleeping for 30 ms before trying again [ 0.160292] [00000e07] libusbx: debug [darwin_cache_device_descriptor] kernel responded with code: 0xe00002ed. sleeping for 30 ms before trying again [ 0.191419] [00000e07] libusbx: debug [darwin_cache_device_descriptor] could not retrieve device descriptor 0a5c:4500: device not responding. skipping device [ 0.191489] [00000e07] libusbx: debug [libusb_unref_device] destroy device 0.0 ... > Finally, you may also notice that the patch is using __linux__ or __APPLE__ > defines, when we could use the OS_LINUX and OS_DARWIN as per in config.h. > The main reason is that, as least for the BSDs, we're likely to have to > split the OS_OPENBSD between __OpenBSD__ and __NetBSD__ anyway, That is quite possible in the future if some NetBSD users found problem. I do not know of any other NetBSD users using libusb-1.0/libusbx yet other than myself. :-) > and we may have to more OS splits in the future, so using the OS_* defines > doesn't help us much. > > > [1] > http://stackoverflow.com/questions/4867839/how-can-i-tell-if-pthread-self-is-the-main-first-thread-in-the-process > [2] http://www.openbsd.org/plus.html > [3] http://source.winehq.org/git/wine.git/?a=blob;f=dlls/ntdll/server.c#l943 > -- 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
