On Thu, Jan 09, 2003 at 06:52:40PM +0100, Srebrenko Sehic wrote: > On Thu, Jan 09, 2003 at 06:34:13PM +0100, Daniel Hartmeier wrote: > > > > But it would be worth carefully looking at the currently shared modules, > > and sorting all functions and shared globals to into either shared or > > private modules. Whether you put the shared code into a library or just > > link an object file from pfctl is then just a detail. :) > > If we leave out all the technical challenges involved, the real question > is if the pf developers find this idea useful at all? The only way libpf > whould ever be a hit is if it was developed/maintained in the official tree. > Otherwise, libpf maintainer would need to do spend a lot of time > figuring out the changes happening to pf, pfctl, authpf, etc. > > How often do pf(4) structures changes? 5 times a week? IMHO, it would be > a mission impossible to maintain it externally.
Right now things are changing too fast. I had to stop working on pftop or risk losing my sanity ;) (Ouch! it is broken again, I will make a new release in a week). I think we need a 'pf version' incremented with api/structure changes. That would really make maintaining portable code MUCH easier. In pftop I only duplicate state/rule printing functions so I have not needed a general purpose library (yet). Though I believe it would be useful if designed/implemented correctly. Can