Subject: Re: Problems with PF_KEY SADB_DUMP
To: Jonathan Stone <email@example.com>
From: Matt Thomas <firstname.lastname@example.org>
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
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
If no record, clear the dump-in-progress flag.
Matt Thomas email: email@example.com
3am Software Foundry www: http://3am-software.com/bio/matt/
Cupertino, CA disclaimer: I avow all knowledge of this