In D9478#195922, @mav wrote:

I have no objections if this information is proven.

I'm not sure how to check "TRIM with NCQ" for sure. fio (benchmarks/fio) could run "trim" task with I/O depth 4 with "posixaio" driver in "direct" mode without problems (with 4K-sized 4K-aligned) requests . Is it enough?

750 reports "Samsung", not "SAMSUNG".

In D9478#195912, @mav wrote:

Is there reason why for ATA "Samsung" is lower-case, while for SATL it is upper-case? Does some SATL implementation convert strings to upper case?

It's my copy'n'paste error. 750 EVO uses "Samsung" according to boot message.

Fix new opcode placement after megre.

Better merge with named states: previous variant was formally correct, but ugly and against any codestyle.

Remove debug output, as this branch is "ok" now.

Diff against r304005, with all conflicts resolved.

In D1776#144733, @julian wrote:

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

I see the points both of you are making.

let's try address some of them (all mixed up):
1/ backwards compatibility. The capacity to process the opcodes generated by an old ipfw(8) when it sees 'keep-state' need to remain in place, and do the same things. We all agree with that. that compatibility doesn't really need to be in place for more that a major release..

In D1776#144162, @ae wrote:

In D1776#144161, @lev wrote:

Ok, and how implement record-state with action triggering in this case?

record-state with action triggering implemented as two rules:

# ipfw add allow tcp from me to any out record-state
# ipfw add check-state

Ok.

Look how it works:
'record-state' is last opcode (O_KEEP_STATE with F_NOT) in the rule and there is no implicit 'check-state'.
So, when packet is matched by this opcode, ipfw_install_state() will create dynamic rule with action that has this rule.
But 'defer-action' effect will be achieved because opcode has F_NOT flag. Look at the end of swich(), the 'match' variable will be set in the O_KEEP_STATE opcode, then 'match' variable will be inversed to zero due to the F_NOT flag. Now we get 'defer-action' effect and the search continues with the next rule. Now you can do NAT and etc.

In D1776#143557, @ae wrote:

After some thoughts, I think your patch can be simplified to only modify ipfw(8).
You can use F_NOT flag to distinguish record-state from keep-state. The rule with such opcode will be not prepended with O_PROBE_STATE.
So, when it will be matched it will call ipfw_install_state(), but after a state creation the rule action will not be applied due to presence of F_NOT flag.
Also 'set-limit' can be implemented in the same way.

Difference between record-state and keep-state is not about immediate action execution, but about implicit check-state. record-state could be encoded as F_NOT and keep-state, but defer-action needs kernel changes anyway

Update diff to latest HEAD version.
Add example for new options to man page.

Fix grammar in man page.
Migrate to latest revision.

I sort of was thinking the 'record-state' command would do nothing except record state.
in other words it would have an impicit "don't do it now", and it would not have an implicit check-state.

It was my first intention because it solves task I had at hands. But after that I've started to explain idea to somebody at ipfw@ list and found that my first approach is not much better than current one, because main problem is this "implicit".

New diff with spelling mistakes fixed. Thanks, Julian!

In D1776#6, @julian wrote:

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.

And same argument in other word: we remove one implicit effect of keep-state and limit (checking of state) and add another one (skipping of action)!

In D1776#6, @julian wrote:

while the 'skip-immediate' is useful, I was thinking that record-state would imply that.

It was first idea. But after some thoughts, I decided, that it is not good enough.