On Sun, 2012-03-25 at 20:51 +0800, rong deng wrote: > Hi all, > > > I would like to apply for logging/testing project. Here's my attempt > to write more about my thoughts on how this should be done: > > > First about logging: > > > 1. pulseaudio has already had some support for log level, but it may > need some improvements. > 2. the category support is not yet. for this aspect, gstreamer does a > much better job. So I would add similar mechanisms for pulseaudio. For > every plugin, we can advocate developers declare a separate category. > And then, we can something familiar as mymodule:4 to log what we want. Both of these sound about right. One thing I particularly like is Rhythmbox' regex based log filters. You can basically only get logs that match a particular filter, which is sometimes even handier than filtering by log categories. Might be overkill for us, and I'm not sure how this impacts performance, but it's something that could be useful. > 3. the idea of a circle buffer is good. therefore, we can create a new > interface "pactl log" to display the log. The same as "dmesg", that > would be great. However, about the details, Lennart has the idea of > using compression for logging for the whole system, we could do the > same if want to put more stuff in the circular buffer. That's interesting. Do we have any information about the size vs. performance trade-off here? > 4. filtering the logs and display the output with colors are nice > features. color output is available right now in pulseaudio, but we > may need to adapt it into different situations, e.g. circular buffer. Definitely -- colours in the logs (GStreamer has these) makes reading and separating out related categories easier. > Then about testing: > > > 1. gcov is all about coverage testing. I'm reading more documents > about this tool. > 2. As I skim through the code of pulseaudio, it seems it lacks the > support for a testing framework. Many unit tests are made by > developers themselves, and are ad hoc. E.g. the testing and benching > program for resampling. > 3. I'm not quite sure about what kind of test framework do we want? > unit test framework? Overall functional framework? For unit testing, > googletest seems to be an option. Or we could write our own? While googletest does look nice, I'd be happier using a C-based framewrok (check, perhaps?) to keep the testing code more in line with the rest of the code base. That said, if you have a convincing argument for features that googletest provides that the popular C-based ones do not, this is not set in stone. > Any thoughts would be welcome. > > > As Arun pointed out, this project might not be enough for GSoC, I'm > also looking for another project. Great, looking forward to seeing your completed proposal. -- Arun
