On Thursday, Jul 3, 2003, at 13:37 US/Pacific, Henning Brauer wrote:
[ on the NATLOOK ioctl ]
changing anything like that becomes less and less acceptable. pf is widely deployed nowadays, and there are more 3rd party apps using the interfaces than we know of. compatibility becomes a major issue.
If it's time to go ahead with something like this, it might not be a bad idea to go farther and break everything at once. Two changes I'd like to see:
- Much more abstraction. Currently most of the ioctl interface is tied directly to the kernel structures, which are less than fun to work with. pf_ioctl.c has to specifically NULLify pointers for example, in case userland touches them. (Speaking of which, DIOCADDSTATE is trouble in -current -- it violates the rule.ptr assumptions). Figuring out how to use the interface is hard as well, since the structures have all this kernel data, and one has to dig through it all to figure out what needs to be filled in and what doesn't. Storing things like anchor, queue and tag names in the kernel on a per-rule basis is kind of silly. Right now it makes sense, but it's still silly, since the kernel uses the faster redundant forms anyway (pointer, id).
Using a completely different structure for the ioctl interface would take care of most of this. It would also insulate some kernel changes from userland, such as additions to pf_state that only have meaning to the kernel.
- Better error reporting. Witness the recent messages involving "DIOCADDALTQ: Invalid argument". Even if it's just an addition to ioctl-specific structs, having pf(4) report something more specific like "too many queues" would be a help.
I'd be willing to do some of the work if it's wanted.
