--4zI0WCX1RcnW9Hbu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 05, 2007 at 08:51:06PM -0700, Darren Reed wrote:
>  The idea with most merit that I've seen is to be able to save and
>  restore socket option state.  Save it into a binary blob using a call
>  to getsockopt() and apply it to another with setsockopt().=20

I don't really like this idea, for a couple of reasons:

 - the "opaque blob" may be manipulated by a malicious program, we
   need to be defensive about not trusting the content in the kernel
   once it's handed back to us.

 - to try and avoid this, if the blob is to be a reference to some
   other storage in the kernel where the real data is, we now have
   another namespace, maybe more interface to manipulate the options
   stored in the blobs, we have storage management to deal with, etc.

Frankly, if you're going to pass something to represent a set of
options to copy, why not just pass the fd of the socket that has
those options set?  That seems like the place to store them without
any of the above issues (or at least, well defined semantics and
tested implementations of those issues :-).

The question then becomes where to put the operation that does this
copying:

 - in a new syscall, as Thor proposes, though I prefer socketlike() as
   a name, and with the single argument.

 - in setsockopt(), with a new variant/magic option that says "make
   the options on this socket the same as that socket" and takes
   another fd-number as the parameter.

 - in the user program, with a different get/setsockprops() interface=20
   (and a blob format whose opacity is the subject of endless debate :)

I like the first as a direct response to the immediate requirement,
but the second or third are more flexible/extensible, in that it could
be applied to existing sockets as well as just at the creation of new
ones, at the cost of one extra syscall in Thor's (and perhaps the most
common?) case.

--
Dan.
--4zI0WCX1RcnW9Hbu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFGjchvEAVxvV4N66cRAuWIAJ0ZyNc6cPDftWEUmociw0iAt5zMPwCgvodz
ssnGde1NFPYF/u3gfMkKgCo=
=6nLg
-----END PGP SIGNATURE-----

--4zI0WCX1RcnW9Hbu--