FreeBSD port of ConsoleKit

[Joe Marcus Clarke]

On Mon, 2007-08-27 at 13:12 -0400, William Jon McCann wrote:
> Hi,
> 
> On 8/26/07, Joe Marcus Clarke <marcus at freebsd.org> wrote:
> > We have a FreeBSD port of CK in a private git repository.  We will be
> > sending patches upstream soon.
> 
> Awesome!  Be sure to check recent git because we've made some changes
> that should make it easier to support different systems (while adding
> Solaris support).

We synced to HEAD a few days ago, so we got all of the recent changes.
In fact, we're ready for you to take our patches.  See
http://git.xbsd.org/?p=freedesktop/consolekit.git;a=shortlog;h=freebsd
for everything you should need.

> 
> > I have a question, though, about the file monitor code.  The code in CK
> > that uses inotify seems very complex.  It's almost like a FAM-lite that
> > emits CK events instead of FAM events.  However, the only consumer of
> > this code is the TTY idle monitor.  I wanted to add kqueue support, but
> > it seems like a wasted effort since kqueue is not as functional as
> > inotify; adding the same level of support to CK would require much more
> > work.
> 
> I don't think it is overly complex.  Yeah, it is only used for the
> idle monitor now but I planned on using it to monitor configuration
> files (for seats etc).  In fact, I should really be hooking this up as
> soon as I can.  In the longer term, I wanted something that would be
> relatively easy to convert to using gvfs monitoring when it is ready.

PolicyKit has the same config file/directory monitoring, but does so in
a much more simplified manner.  That was trivial to port to kqueue since
we don't have to worry about handing the specific changes back to PK
(see
http://git.xbsd.org/?p=freedesktop/policykit.git;a=shortlog;h=freebsd
for patches).

Given the fact that a lot of these projects seem to be rolling their own
monitoring code, it might make sense to create one external library for
this (and maybe that's the plan with gvfs).

> 
> > Therefore, my question is, could the CK monitor code be simplified and
> > tailored just to do the file access stuff (i.e. will external consumers
> > of CK need this extensive monitoring capability, or can they just use
> > FAM on their own)?  Alternatively, could FAM (e.g. gamin) be used
> > instead of embedded code to do a similar task?  If we link with FAM, all
> > of the heavy lifting is done for us already.
> 
> At least on Linux, I don't want to have an external dependency on FAM
> or gamin.  But you can probably add a FAM or gamin backend for use on
> BSD if you want.  I think gnome-menus has a FAM backend that you may
> be able to adapt.

Yeah, I think I will check on that.  The one thing FAM doesn't do well
is access time monitoring, but I think I can adapt kqueue for that
specific task.

Joe

-- 
Joe Marcus Clarke
FreeBSD GNOME Team      ::      gnome at FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/hal/attachments/20070827/f895f875/attachment.pgp