From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jason at zx2c4.com (Jason A. Donenfeld) Date: Fri, 10 Jan 2014 19:00:16 +0100 Subject: RFE: .so filters In-Reply-To: <20140110172052.GP7608@serenity.lan> References: <20140109225802.GM7608@serenity.lan> <20140110090639.GN7608@serenity.lan> <52D029F9.40805@xinu.at> <20140110172052.GP7608@serenity.lan> Message-ID: On Fri, Jan 10, 2014 at 6:20 PM, John Keeping wrote: > > I was also wondering if supporting "unix:/path/to/socket" would be > useful, then the filter would connect on a Unix socket, run and > disconnect, on the assumption that the administrator has a daemon > running to do the filtering. This has few benefits, and you still have the out of band signaling issues. Sysadmins don't want to run more daemons. > > If we're introducing this ":" support then it would be good > to do it in a reasonably generic way so that any types that add new > dependencies can be compiled out easily. Maybe a table like this? > > struct filter_handler handlers[] = { > { "unix", open_unix_socket_filter, close_unix_socket_filter }, > { "persistent", "open_persistent_filter, close_persistent_filter }, > #ifndef NO_LUA > { "lua", open_lua_filter, close_lua_filter }, > #endif > }; This would make more sense. Look at the commit I just merged to master where I split filters out into filter.c. This would be the place for such a function pointer table. > I might have a look at the Lua case over the weekend if no one beats me > to it. Cool. Please take in mind the design considerations in the email I just sent to Florian with the tree functions... Before you begin, take a peak at jd/gravatar and jd/persistent. Can't wait to see what you come up with!