On 2013-08-13 22:13:55, Tyler Hicks wrote: > Integrate dbus tests into the regression testing framework. > > This started out as dbus-send.c, from the dbus source, and then grew > from there. > > dbus_message is an example "client" program that only sends out > messages. dbus_service binds to a well-known name and then listens and > responds to incoming messages. They share some code in dbus_common.c. > > The test scripts, dbus_message.sh and dbus_service.sh, share some > functionality in dbus.inc. > > Signed-off-by: Tyler Hicks <[email protected]> > --- > > * Changes in v3: > - Add <apparmor mode="required"/> to dbus.conf to ensure that dbus-daemon > will either enforce AppArmor mediation or fail to run if AppArmor D-Bus > mediation is not available > - Do a best effort attempt to detect if dbus-daemon initialization was > successful in dbus.inc:start_bus(). A sleep and kill -0 isn't ideal, but > dbus-daemon forks before initialization is complete. > - Fix fatalerror message in dbus.inc:send() so that it correctly prints the > message type (thanks for pointing this out, Seth!) > - Unify error paths in dbus_service.c:main() > - Introduce an unlock_fd() function that is called from > dbus_service.c:main()'s error path. This makes sure that the fd that was > pre-locked by dbus_service.sh is always unlocked. > - Set up signal handling a earlier in dbus_service.c:main() > - Stop using runchecktest() in dbus_service.sh. Instead, wrap > service_runtestbg() and service_checktestbg() with service_runchecktest() > and use that in the two remaining runchecktest() call sites. This, along > with the unlock_fd() change and <apparmor mode="required"/> changes above, > fixes a hang that Jamie was seeing. > - Run dbus_{message,service,common}.c through the kernel's scripts/Lindent > script to make the coding style less like D-Bus and more like AppArmor. > Those source files only vaguely resemble D-Bus' dbus_send.c now, so > there's > little value in sticking with the D-Bus coding style. > > That last bullet point obviously makes it difficult to diff v2 and v3. If it > would be helpful to see an incremental diff between v2 and v3, before I ran > the > .c files through Lindent, I can easily send it out. Just let me know. > > Seth gave v2 an ack, but v3 changes enough that I didn't feel comfortable > carrying that ack over. John gave v1 a tentative ack and I plan on waiting for > a solid ack from him on v3 before committing it to trunk.
I'm sure that JJ hasn't had a chance to take a closer look like he had wanted to, but I did address his feedback from his v1 review. Also, Seth gave me an ack for v3. I think it is best to go ahead and commit v3 to trunk at this point. JJ - if you do get a chance to look at these tests and have improvements that you'd like to see, I'll obviously be more than happy to make those changes. There are some more D-Bus tests that I plan on adding before 3.0 is released, but this is a really good start that exercises the core functionality of D-Bus mediation. Tyler
signature.asc
Description: Digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
