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

On Fri, Jul 06, 2007 at 01:02:04AM -0400, der Mouse wrote:
> I'm thinking something like array of packed struct { unsigned char opt;
> int value; } (mutatis mutandis for options not using int)

As I suggested earlier, *if* we were to go down this path, we already
have proplib for marshalling mutatis mutandis.  There's more structure
here, remember: options at several protocol levels, for starters.

> though of course the details would be private to the kernel.=20

though of course proplib has the benefit of not being opaque to the
user process (so it could manipulate/filter/examine the option set
without needing any syscalls).

> If the kernel finds an invalid option, or value, in the blob, it
> would fail the set call, just as it would a setsockopt call that got
> passed similar garbage.

And here we have the atomicity issue: the kernel would have to check
them all for syntax validity first (what kind of syntax and existing
tools might be handy for that, I wonder?) before setting any options.

Then it would also have to check the full set of options in the blob,
and the ones already on the socket, for mutual consistency and
compatibility, etc.  That checking currently gets done as the options
are set, and would have to be duplicated or factored out, otherwise
we'd then need code to roll back all the previous options from the
blob when one fails, and the side-effects they may have, and so on..

Oh, and it might be nice to tell the user which option in the blob
caused the problem if we can, which rather implies that the blob not
be opaque.

Once again, proplib offers opportunities here (since this kind of work
was its design purpose), but it's a rather more ambitious exercise
than the present proposal requires. =20

So once again: I think if someone wanted to go down this road for some
reason, this would be the right way for them to do it.  For all that
the academic discussion is interesting, I'm pretty sure we don't
presently have the reason, and quite sure we don't have the someone.

Until and unless, doing the copy in a socketlike() avoids all the
conflict and checking issues, since it copies state that is already
valid and doesn't have to merge it with anything else.

> >  - 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, [...]
>=20
> Oh, ugh.  I like that about as much as you seem to.  :-?

Right.

> > 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?
>=20
> It requires that that socket still exist.  I see no particular reason
> to demand one file descriptor be kept open per set of options, rather
> than storing just the useful information.

True, but that's a feature by the point we agree on above - the fd
already has all the properties we want as a storage handle, including
doing all the cleanup on close.

--
Dan.

--HeFlAV5LIbMFYYuh
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGjdbaEAVxvV4N66cRAhWzAKDv/1phXTe4NYLwryyMCHr+ka7yQgCfYn8U
QWpv6rOrINm2nWcdfbGm8hw=
=abAt
-----END PGP SIGNATURE-----

--HeFlAV5LIbMFYYuh--