On Wed, May 20, 2009 at 08:50:44PM -0700, David Miller wrote:
quoted text
> From: Neil Horman <nhorman@tuxdriver.com>
> Date: Wed, 20 May 2009 22:26:21 -0400
> 
> > I agree, your way of doing this definately lets you layer on top of
> > the existing vetted implementation, which is nice, I just thought
> > that avoiding the creation of another syscall might be worth a
> > little extra work in the kernel.  Instead of arrays of msghdrs, We'd
> > be looking at chains like this: msghdr->(struct msghdr
> > *)msg_control[i].data->msghdr->etc
> > 
> > Not too hard to parse, I dont think.  But I'll defer to brighter
> > minds than mine.  If the creation of another syscall isn't too
> > difficult a barrier to overcome (assuming this is going to occur for
> > sendmsg, and various other i/o ops as well), then your way here is
> > probably the way to go.
> 
> Unfortunately you can't use msg flags for this.
> 
> We accept any message flag we don't understand without signalling
> any errors.
> 

I assume that silently ignoring flags we don't understand is a specified part
of the sockets api?  I was looking at the posix definition of recvmsg and I
don't see where its required that we ignore unknown flags (although I can see
why it would be usefull to do so)

quoted text
> So there is no way to determine if the kernel supports the flag
> or not.  Whereas with a socket option, we'll always get an error
> on older kernels for unsupported options.
> 
> I think the system call is the cleanest, because it's not only a
> semantic change but also a data type change.  I also think the
> socket option scheme is too cumbersome.  I think it would be
> common for an application to want to use both modes of sending,
> especially if that application uses lots of existing library
> mode to compose some messages.  And extra setsockopt() around
> every call down into that library?  Yikes, good luck getting
> that right all the time.  It's way too error prone.

The new system call is definately cleaner, as it lets you specify the array
semantics in a way that is much more efficient and less cumbersome for both user
and kernel space.  I just thought I'd propose an alternate method that avoids
the need for a new syscall.  It sounds like you and Acme have already hashed
through this though, so I'll sit down :)

Thanks guys!
Neil

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html