Re: CVS commit: src/sys/arch/i386/conf

2013-11-26 Thread Alan Barrett

On Fri, 22 Nov 2013, Jeff Rizzo wrote:

Modified Files:
src/sys/arch/i386/conf: ALL

Log Message:
Comment out npf for now, as we can't have both NPF and PF in the
same kernel


It used to be possible to have npf and pf in the same kernel.  The 
kernel I am running now (built a few weeks ago) has both.


I think it's important for users to be able to have both.  If I 
want to migrate from pf to npf, then part of my testing would 
probably involve switching back and forth a few times to check 
that the npf rules do the same job as the pf rules, and I would 
want to be able to do that without booting a different kernel for 
every test.



- rmind has said he'll address this eventually,


OK.

--apb (Alan Barrett)


Re: CVS commit: src/sys

2013-11-26 Thread Christos Zoulas
In article 20131126095505.gj1...@apb-laptoy.apb.alt.za,
Alan Barrett  a...@cequrux.com wrote:
On Sat, 23 Nov 2013, Jeff Rizzo wrote:
Log Message:
Since mountlist is now a TAILQ, convert some missed usages
so things build again.

It would be better if the callers were rewritten to use the 
queue.h macros instead of direct access to the struct members. 
(Especially since the names of the struct members are not part of 
the documented API.)

For example, this ...

-for (mp = mountlist.cqh_first; mp != (void*)mountlist; mp = nmp) {
- nmp = mp-mnt_list.cqe_next;
+for (mp = mountlist.tqh_first; mp != (void*)mountlist; mp = nmp) {
+ nmp = mp-mnt_list.tqe_next;

... could be rewritten to use TAILQ_FOREACH.

Not to mention tht this is wrong... It should be:
for (mp = mountlist.tqh_first; mp != NULL; mp = nmp) {

But I thought I fixed them all? I will check again.

christos



Re: CVS commit: src/sys

2013-11-26 Thread Dennis Ferguson

On 26 Nov, 2013, at 01:55 , Alan Barrett a...@cequrux.com wrote:
 -for (mp = mountlist.cqh_first; mp != (void*)mountlist; mp = nmp) {
 -nmp = mp-mnt_list.cqe_next;
 +for (mp = mountlist.tqh_first; mp != (void*)mountlist; mp = nmp) {
 +nmp = mp-mnt_list.tqe_next;
 
 ... could be rewritten to use TAILQ_FOREACH.

Actually not TAILQ_FOREACH, but TAILQ_FOREACH_SAFE, though the operation
of the latter is obscure enough that one could be forgiven for writing
code that makes what is needed explicit.

For a minimal improvement just TAILQ_FIRST and TAILQ_NEXT would be good.

Dennis Ferguson