his "feature" is I believe still needed. I am keeping this alive to help me remember the details and to flag it to others.

was this ever done?

I note that the package is now up to 9.mumble so this should either happen or not. (with the new version) I know several companies that use the script so it is important that the script be kept compatible.

yes, only ipv4 packets should be processed. what actually exploded?

change review outcome

OR do
#ifdef NGM_BRIDGE_TABLE_ABI
if ((msg->header.typecookie == NGM_BRIDGE_GET_CONFIG )||

 (msg->header.typecookie  == NGM_BRIDGE_SET_CONFIG) ||
 (msg->header.typecookie  == NGM_BRIDGE_GET_TABLE) ) {
    ..... new code....
} else

#endif
... old code

one possible solution to stop the commands from being run a second time. replace 'break' with a goto.. OR poison message->cmd so it wont match next time?

I wasn't saing you shoudl force yourself to do the test.. just whether it is theoretically possible,, anyhow I'm happy with the result. Don't let me stop you from committing it and I would say that the only case for keeping it in 13 is for the brief period while an upgrade is occurring. (for example I know people who have their interface connected into a bridge so that if the bridge wasn't configured correctly they'd be off the air.. It would basically be for compatibility up the 12 line rather than being needed in the 13 line.

That's why I added the cookies to the API.

Can you use both binaries? e.g. a script uses one and manually you use a newer one?

It should be backward compatible for 12 at least. Probably not needed for 13 but no harm in carrying it for one release.

experimenting with the pastbin.. ignore..

I have a similar crash at $JOB. Occured during shutdown

only one thought really.

In D15247#323507, @eugen_grosbein.net wrote:

In D15247#323501, @avg wrote:

It would be nice to add a mention of rc.resume and the new resume keyword to rc(8) as Julian suggested.

I would rather not duplicate same documentation in different places.
/etc/rc.resume is not used for auto-reboot nor general daemon startup described in rc(8).

Do you have any idea how to mention rc.resume in rc(8) correctly?

docs needed

should probably be documented somewhere.
mabe add a cross ref (see also) in the rc and rcorder man pages and add sections to whatever man pages mention how to resume (or add one)

happy but not able to test right now..

Can we make a list of other things that we'd need to change?
ABIs for Start

In D14608#306803, @imp wrote:

I'm curious why you don't setup a kqueue event structure to point to the file and then just poll it each time through. That would be no more expensive than the time() call, and you would have no lags. Would also save all the stat calls too, which would be a win.

Despite my grumpy responses (Get off my lawn!) I appreciate the comments.. At least you didn't say "What a stupid idea, who would want to do that?" Anyhow you've given me some things to think about which is the aim. right?

In D4154#295111, @kevin.bowling_kev009.com wrote:

This was committed over 2 years ago. So that sounds like a pretty local mod. I would recommend either carrying it in your local tree or otherwise upstreaming the estimator.

that's what we are doing (just adding the fields back locally..
The estimator is, unfortunately, a bit crude for public consumption, or I'd commit it.

I tried to read the introduction with a web browser (it's a .html) but it stuck it all together..
can you add some basic formatting?

dammit we have a functional bandwidth estimator that used this field..

is there a formatted version of this available somewhere so it can be read in final form?

Have applied this patch at $JOB now to stable/10

what are the chances of this improvement making it into stable/10?

really minor things only.. don't get discouraged..

I've applied these changes to 10.3 and will give them a run..

so there are bits of this missing if you are (like us) trying to make this work in stable/10 or stable/11 because Isilon have already aommitted parts of it..
like change 313475 for example..
I need to merge that into our 10 based code until I can use this..

In D12330#255757, @cem wrote:

It seems that ZFS (which we don't use) has some ABI dependency on these constants via zfs_cmd, and this change breaks a CTASSERT on line 202 of zfs_ioctl.c. For some reason passing 3 MAXPATHLENs and 1 MAXNAMELEN via ioctl is too much. Someone would need to figure out how to fix ZFS to use this patch.

Very glad to see this. at $JOB we create an appliance and we have ami, azure and vmware versions and I can predict that google-compute is on the Horizon (actually it's already prototyped).
so I'm sure I will get to know and love (?) this port .. :-)

In D10006#206784, @gnn wrote:

New, BSD license, code does not need to be in cddl. Most of the new D scripts and programs go into either share/dtrace or the DTrace Toolkit port. Since this is a script I'd put it into share/dtrace if you want it in the src tree.

so, like is this getting committed some time?

DOn't see issues in this code but see other comment

looks ok.
Who;s going to commit?
any doc change required?

note that this was committed

In D9932#205427, @imp wrote:

In D9932#205419, @julian wrote:

just my $0.02

Nice two cents. Not going to do it since it is beyond the scope of this work, but it is a nice idea down the road. Similar to libnames.mk, it would make things better. But there's a lot of them in the tree, so that's outside the scope.

just an idea for sometime

we are going to run out of available tricks for this in ipfw at some stage.. Can we re-use () like used in table? or make the : part of the keep-state.. so that "keep_state: state1" or keep_state(state1) vs "keep_state :state1"

just my $0.02

will work on this this a bit more this weekend

In D9917#204859, @rgrimes wrote:

First off in the unix philosophy /we also be adding a relname in the spirit of
basename and dirname that calls this library so that any shell script or
Makefile, etc could easily add this functionality?

p.s. I'm still considering line 266/267 in ln.c which came with the original patch, but I have not totally understood yet..

Bapt has convinced me to add these functions to libutil instead of keeping them in libpathconv as they originally came.
The Pathconvert package has been incorporated over the years into many projects.
The simplest way to see how to use this is to imagine how difficult it can be sometimes to generate relative symlinks when installing packages or generated binaries when the source and destination are not fixed relative to each other but expressed as two absolute paths. This becomes trivial by adding the -r option and specifying the available absolute paths. I originally started checking this in as libpathconv, before Bapt got to m. I will remove that at the same time I add this.

I think that "collision" is ok.

In D5017#196563, @pkelsey wrote:

This is the source comment that should have been submitted with my 'request for change' action, had I pressed the buttons in a way that didn't dispose of it instead.

so what change did pkelsey request? I can't see any request to change anything.

who is this mysterious group reviewer "transport"? And where is their negative review? I only see gnn's

my only comment is that I ask you to just confirm that a listening socket can not collide with the socket we are allocating.
i don't think it does, but I may have missed something

As long as features are DISABLED and not removed (e.g. at $JOB we need MD2) then ok.
I think we should make two versions of this port: openssl and openssl-insecure, which has features like sslv2 and MD2 enabled for people who need that functionality. (e.g. for talking to old machines or handling old certificates etc.)
maybe with a different .so number. (just an idea).

as far as I can see it looks good. Same default value as before..

Considering how much work went into writing this and the fact that we had to get it approved by verizon (or whatever they were called at the time) its amazing that I remember almost nothing about how it works.

we should probably skip ports that have a listenig socket on them.. do we?

looks good to me. Hit this in 10.3

this is obviously part of a bigger change, so I can't comment on that part but the part about the EXTRA_PATCH_TREE looks like it should work.
I don't see why one would have a compressed patch file but handling it shouldn't hurt. (except by hiding bugs through added complexity.)