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] [0000040c] libusbx: debug [libusb_close] > [ 2.636405] [0000040c] libusbx: debug [libusb_unref_device] destroy device 1.2 > [ 2.652005] [0000040c] libusbx: debug [libusb_exit] > [ 2.652005] [0000040c] libusbx: debug [libusb_exit] destroying default context > [ 2.652005] [0000040c] libusbx: debug [usbi_remove_pollfd] remove fd 3 > [ 2.652005] [000003a0] 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
