>> I'm thinking something like [...]
> 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.

Proplib occurred to me.  I'm not convinced it is a right answer (but
also definitely not convinced it is a wrong answer).

>> though of course the details would be private to the kernel.
> 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).

This may or may not be a benefit.  It's a benefit in that it turns the
"apply these settings" call into a general-purpose multi-option
setsockopt.  It's a drawback in that it commits the kernel to
supporting a general-purpose multi-option setsockopt with a proplib
interface, which making it an opaque blob (which just currently happens
to be a proplib serialization) doesn't.

>> 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.

Not necessarily.  I see nothing wrong with documentation language like
"if an error occurs, some of the options contained in the blob may get
set anyway".

> 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.

Again, not necessarily; the semantics could be defined as something
like "this call is semantically equivalent to multiple setsockopt calls
setting the same options in some unspecified order, stopping at the
first error", with all the consistency and compatability implications
that has.

> 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.

Well, it would imply that.  I'm not sure that's necessary, or even very
desirable; it makes sense only if the blob decomposes into a sequence
of option-and-value settings.  (For example, I could see it containing
a copy of so_options directly, rather than broken out into individual
options.)  If it's an opaque blob that was generated legitimately (ie,
with the "get" call on a socket of the same family/type/protocol), any
error is a can't-happen; otherwise, userland is either busted or trying
to fool the kernel, and either way I'm not sure there's value in trying
to say exactly what's wrong.

>>> [...] why not just pass the fd of the socket that has those options
>>> set?
>> I see no particular reason to demand one file descriptor be kept
>> open per set of options [...]
> True, but that's a feature by the point we agree on above -

Which point do you mean?

> the fd already has all the properties we want as a storage handle,
> including doing all the cleanup on close.

Actually, it lacks some properties I think could be good, such as being
able to be stored in and retrieved from a file, and not consuming a
relatively scarce resource (file descriptor space).

Anyway, you're certainly right that this is all academic until and
unless someone comes along with a use for it and volunteers to create
an implementation.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B