looks reasonable, but am unsure of all the possible cases for *end given garbage input

I'd still vote for using rcvif if a new field is out of the question.

This shoudn't be needed.. it should be panic condition if item is NULL.

ok so I see the points of both of you.. hmm that doesn't sound very english.. let's try again..

seems ok from the quick look I gave it
We've needed this feature for a long time.

some pointers to references on hardware pacing and how it works might be useful.

this can already be done using dummy net.. Just set a tag/flag on the socket so that ipfw can identify it.

looks about right but I'm not current with all the internal functions. I also want more eyes, but I like it generally.

In D5017#106574, @gnn wrote:

I'm a bit confused by this proposal. No protocol I know of has a port field larger than 16 bits. How and where might this be applied?

just a nit

My only comment is that if you have a simple enough test.. i.e. "are there any policies (regardless of direction) then I'd go for guarding the callers rather that returning immediately.. in other words don't even do the call.
amd64 may have very cheap function calls but they still cause register spills etc. some other processors may cost more..

If you are going to replace a file, then you need to have a big banner in that file saying
"this file will be replaced automaitcally on upgrade. Do not edit it.
Please put any local changes in /boot/rc.loader.local"

AS I said before, I can see a use of much of this but I think I would still settle for a version of "keep-state" that sets the state without checking it (except to look for duplicates). If you are being blocked by the nefarious melifaro then maybe a subset that just implements "set-state" would surfice. .

probably ok but could do with an example or better comments

I don't mind if people leave them out but I do prefer to see them in, especially if there are other clauses. This is true in if, for, while, etc.... gratuitously removing them makes the single line clauses not match the multiple line clauses in style.
I really hate if-elseif-elseif-elseif-else chains where some clauses have them, and some do not.

this is a superset of what I would have done.. thanks for fixing the grammar.

in case I didn't point you at this before...
http://p4web.freebsd.org/@md=d&cd=//depot/projects/vimage/&cdf=//depot/projects/vimage/porting_to_vimage.txt&c=win@//depot/projects/vimage/porting_to_vimage.txt?ac=22

Committed as @rS282485.

patch committed. (and then some changes added to the comments and man page by jhb)

Is the reason here to just make the lines shorter or is there a deeper reason? (e.g. to prepare for some upcoming change)

R U SERIUS?

missed one... or, rather, I got it wrong the first time.

while the 'skip-immediate' is useful, I was thinking that record-state would imply that.
skip immediate is only useful with state storage, so I don't see a reason to make it generally available.

I can see you speak a language similar to russian or polish . :-)

let me see if this is correct..
I'm assuming that the reference count can not change if you hold the lock?
if so then before releasing the lock, we can check if the count is 1.. if it is then we are the only person who even knows where this thing is so there can't be any new references added..
having stopped the callout action from happening we inherit it's reference.

In D1711#66, @rrs wrote:

GUYS! stoppit! your arguing cross purposes and getting all hot under the collar for no reason!

Nathan, I do understand your thoughts about whether adding a library just for the installer and configuration tool is worth it, but then I found on trying it out that I think the responsiveness and improved feedback made the install just that bit nicer. The code is there, and its written, and it has a maintainer.
I know that dialog is buggy in many cases and having a pre-canned way to use it would have saved me much pain several years back when I needed it, so I sort of hope that having this library available to work with dialog might actually eventually simplify the base application a bit . The hidden parts of this are of course that when the library is available, it works with xdialog as well and gives a unified look and feel to both environments.

oh yeah.. I have no real problems with it. only the style nits pointed out elsewhere.

seems to act as advertised. maybe it will give a common feel to a bunch of tools.. I think you said ti would work with Xdialog too? or was that my imagination?