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
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
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
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 useful
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 useful as
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
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
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
> 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
> (*) 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 linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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:
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:
(*) 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 linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
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
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).
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:
(*) 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 add one
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
arbitrarily
20 matches
Mail list logo
