After some of the comments by Tvrtko Ursulin and discussions I have had
with other developers, I began looking through the Dazuko source. This
led me to come to some conclusions about much needed changes (and
improvements). The changes will be added for the upcoming 3.0 version,
but I fear that the 3.0 version may not stabilize fast enough. And these
changes can be useful to developers _now_. For this reason, I will begin
working on a 2.5 branch that will incorporate these changes. The 2.5.0
version will appear very soon (most likely directly following the 2.3.3
release). Here is the list of scheduled changes:
- The use of __d_path(), the chroot option, and the need to grab the
system's root mount on startup will be removed! Instead, Dazuko will use
only the d_path() function (but in a different context). By using
d_path() within the context of the registered application (as opposed to
__d_path() within the context of the event-causing-process), Dazuko will
still be able to do full pathname lookups. These changes will fix many
headaches for Linux as well as FreeBSD.
- Registered applications will never receive events generated by other
registered applications (or their trusted applications). However, new
access mask flags will be made available so that a registered
application can request to receive the events generated by other
registered applications. (Currently, only EXEC events from one
registered group are sent to the others. This is a behavioural change in
- Registered groups will be cleaned up after all registered applications
of that group have left. Currently old groups are not being cleaned up
(until the module is unloaded) which causes problems if 5 different
groups have already come and gone.
- The "mode" within the dazukoRegister() function will be expanded to
support 'c'. This is an extra flag that tells Dazuko that the
dazukoRegister() function should only be successful if this register
causes the creation of the group. This can be useful for developers that
want to be sure that they aren't registering to an existing group (which
may be in use by another application).
All of these changes are backwards compatible. I am quite excited about
it and I consider these to be significant enhancements (even if they may
not seem so at first).
The reason I am jumping to 2.5.0 is because the new version will involve
API extensions. With such "round" version numbers, it is easier to
remember what features appeared when.