Subject: Re: Problems with PF_KEY SADB_DUMP
To: Matt Thomas <firstname.lastname@example.org>
From: Jonathan Stone <email@example.com>
Date: 09/19/2003 16:43:24
>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.
Or we could return the data in one monster socket-layer message, and
(as I think you're suggest here) have the pcb-specific code pares
those into individual records (recv*() units), keep an internal
cursor, and return them one at a time.
Either one is quite different from the original suggestion of doing a
big uiomove() directly into the requesting user app. (Unless you want
to replace recv*() with a userspace routine[dlibrary which does a
syscall with a big uiomove() upfront, and fakes subsequent recv()*
calls by returning data from the big userspace buffer?)
Matt, are we just differing over terms? No aggro here: I would prefer
a fix that doesn't involve reworking the socket layer, and if I'm
missing something, please do tell me what it is.