On Wed, Jan 04, 2006 at 02:00:56PM -0600, Bill Marquette wrote: > Reforwarding this...it was the holidays so maybe it got missed. > Anyone? Thanks!
The queue id (ALTQ uses numerical ids, the names are just a convenient mapping provided by pf) is indeed not stored in the state entry at all. Instead, a state entry points to the rule that created it (struct pf_state.rule.ptr), which contains the queue ids (struct pf_rule.qid and .pqid). Since a state entry can persist after the rule that created it is removed from the active ruleset, the kernel keeps rules around as long as they are referenced by any state. In this case, it's not even possible to find a rule referenced by rule number in pfctl -vvss output with pfctl -vvsr (as that wouldn't print the rule anymore). If you want to merely print the queue ids used by each state entry with pfctl -vvss, the easiest way would probably be to extend the structure passed by DIOCGETSTATE to include them, pretending to userland that the state entry actually contains the queue id itself. If you want to actually modify the queue ids used by the state entry, it might be time to introduce the qid and pqid fields into the pf_state structure itself, copy them on state creation from the rule, and from then on only use the values in the state. To start with, that's just a (minor, 8 bytes per state entry) redundancy, but probably a requirement if you then want to add ioctls that modify the values in a state entry. Modifying the (possibly invisible, because already removed) underlying rule would have a different effect, changing queueing for all states created from that rule (if there are multiple). I don't know what you'd consider more useful. Referencing a state entry through ioctl is simpler than referencing a (potentially inactive) rule, I think. I guess if you provide the additional features making good use of the redundancy, and they are considered generally useful (think of some convincing real-life examples of when you want to change queueing of an existing state ;), it will be accepted. Daniel
