Subject: Re: Problems with PF_KEY SADB_DUMP
To: Jonathan Stone <jonathan@dsg.stanford.edu>
From: Matt Thomas <matt@3am-software.com>
List: tech-net
Date: 09/19/2003 18:05:21
On Friday, September 19, 2003, at 04:43 PM, Jonathan Stone wrote:

>
>> Not true.  You just need to keep more state in the pcb to track this.
>
> Huh? I supppose we *could* invent a new, PF_KEY specific, way of
> encoding small messages with record boundaries, such that we can fill
> an mbuf cluster (or chain of densely-packed mbuf clusters) with tiny
> messages, while still tracking reconrd boundaries and whatever else
> sbappendaddr() keeps now.

Nothing that complex needs to be done.  Simply keep a context in the pcb
and use PRU_RCVD.  When you receive SADB_DUMP, set a flag indicating a
dump requested.  If so_rcv.sb_mb == NULL, then place the first record 
into
the so_rcv, and set a flag indicating dump in progress (clear dump
requested) and that you are at record #1.  If so_rcv.sb_mb != NULL,
wait until the usrreq is called with PRU_RCVD and sb_mb == NULL, then
set the dump-in-progress flag and put the first record into so_rcv and
set context to record #1.  The next time PRU_RCVD is called, check
dump-in-progress and grab the next record and advance the record 
counter.
If no record, clear the dump-in-progress flag.
-- 
Matt Thomas                     email: matt@3am-software.com
3am Software Foundry              www: http://3am-software.com/bio/matt/
Cupertino, CA              disclaimer: I avow all knowledge of this 
message.