On Thu, Jan 09, 2003 at 09:43:34PM +0100, Daniel Hartmeier wrote:
> As for a library, that would only make sense if it were an additional
> abstraction layer somewhere between pf(4) ioctls and pfctl command line.
> Whether you find a level that changes less often than pf(4) but is more
> generic than pfctl decides how useful it would be. If it changes with
> each pf(4) change, it will just be another piece in the puzzle to update
> everytime, increasing the amount of work caused by changes.
Good abstraction layer is possible. I don't really see why a library
'hiding' the behind the scene changes happening to pf could cause more
grief. In fact, even the in tree things (authpf, pfsync, whatever) might
benefit from that. Imagine,
#include <libpf.h>
int ret = insert_pf_rule("block in from 192.168.0.1 to any");
Perhaps I'm asking for too much, but that would be nice.
> I don't suggest that userland tools like libdnet, pftop, symon, etc.
> should immediately adjust to all -current changes in pf. It's probably
> enough if they just provide one working source for each OpenBSD
> -release/-stable.
Perhaps. But if you have a single box and want to follow -current, but
you also want to maintain a piece of software, that becomes rather
difficult ;)
> If you want an update to -current, mail me, I'll happily adjust your
> source to -current. It causes me less work to adjust a handful of userland
> tools than maintaining a library. :)
Heh. Thanks for the offer, but I can do that myself. As Car mentioned
before, you might go mad after a couple of -current synchs. It might be a
handful of tools now, but with a decent library API, there might be many more.
But ok, I'll shut up now.
// haver
