David Howells <[EMAIL PROTECTED]> wrote:
> > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
> > fixed one day as its useful to find out the sizeof message pending when
> > combined with MSG_PEEK
>
> Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be usefu
David Howells <[EMAIL PROTECTED]> wrote:
> > > - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
> > > fixed one day as its useful to find out the sizeof message pending when
> > > combined with MSG_PEEK
> >
> > Hmmm... I hadn't considered that. I assumed MSG_TRUNC not
David Howells <[EMAIL PROTECTED]> wrote:
> > - Why does rxrpc_writable always return 0 ?
>
> Good point. That's slightly tricky to deal with as output messages don't
> remain queued on the socket struct itself. Hmmm...
Okay, I've fixed that by changing it to:
static inline int rxrpc_w
Alan Cox <[EMAIL PROTECTED]> wrote:
> - recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
> fixed one day as its useful to find out the sizeof message pending when
> combined with MSG_PEEK
Hmmm... I hadn't considered that. I assumed MSG_TRUNC not to be useful as
arbitraril
Alan Cox <[EMAIL PROTECTED]> wrote:
> > (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the
> > "type" argument to socket().
>
> This is also incorrect
Sigh.
And what would you have me do? There *isn't* an appropriate SOCK_xxx constant
available, and you won't let me ad
Ok quickly going over the code that hasn't made the list
- recvmsg not supporting MSG_TRUNC is rather weird and really ought to be
fixed one day as its useful to find out the sizeof message pending when
combined with MSG_PEEK
- RXRPC_MIN_SECURITY_LEVEL reads into rx->min_sec_level and then if it
Alan Cox <[EMAIL PROTECTED]> wrote:
> Some of them don't seem to be making it through to the list and are
> dropped each time btw
Yeah. It's a size issue. The fifth patch is a third of a megabyte. The
patches at the URLs should now be updated (I'd forgotten to do that before
sending the emails
> These patches together supply secure client-side RxRPC connectivity as a Linux
> kernel socket family. Only the transport/session side is supplied - the
> presentation side (marshalling the data) is left to the client. Copies of the
> patches can be found here:
Some of them don't seem to be ma
> (*) SOCK_RPC has been removed. AF_RXRPC sockets now simply ignore the "type"
> argument to socket().
This is also incorrect
NAK
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
These patches together supply secure client-side RxRPC connectivity as a Linux
kernel socket family. Only the transport/session side is supplied - the
presentation side (marshalling the data) is left to the client. Copies of the
patches can be found here:
http://people.redhat.com/~dhowe
10 matches
Mail list logo
