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
David Miller <[EMAIL PROTECTED]> wrote:
> David we're not looking for a precise match, so please stop
> discussing this in those terms. We're looking for something
> close enough.
But we don't have one that's close. Let me recap: according to Alan's
definitions, all (presumably all non-RAW) net
Alan Cox <[EMAIL PROTECTED]> wrote:
> O> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
> > service.
>
> Thats funny UDP receives and sends packets.
I meant that the protocol ships a datagram from one peer to another, but
there's no tie at the protocol level to any d
From: David Howells <[EMAIL PROTECTED]>
Date: Mon, 19 Mar 2007 15:41:38 +
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > So use SOCK_DGRAM, its clearly near enough.
>
> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
> service.
David we're not looking for a precise
O> No, it's not. SOCK_DGRAM is an unreliable, unidirectional datagram passing
> service.
Thats funny UDP receives and sends packets.
-
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.org/m
Alan Cox <[EMAIL PROTECTED]> wrote:
> > > Other RPC types use normal socket types.
> >
> > They do? Examples please. I didn't think Linux, at least, has any other
> > RPC socket families, though I could be wrong as I haven't made a thorough
> > study of them.
>
> SunRPC is implemented in user
> > Other RPC types use normal socket types.
>
> They do? Examples please. I didn't think Linux, at least, has any other RPC
> socket families, though I could be wrong as I haven't made a thorough study of
> them.
SunRPC is implemented in user space and uses the existing TCP/IP layer
and socket
Alan Cox <[EMAIL PROTECTED]> wrote:
> > message transmission. You yourself defined RDM to be a datagram service.
> > RxRPC is not, in my opinion, a datagram service, and neither is it a stream
> > service.
>
> Message is what I should have said.
socket(2) also says datagram...
> Which is just
> message transmission. You yourself defined RDM to be a datagram service.
> RxRPC is not, in my opinion, a datagram service, and neither is it a stream
> service.
Message is what I should have said.
> Interestingly, searching for SOCK_RDM definitions with google shows there's
> some disagreemen
Alan Cox <[EMAIL PROTECTED]> wrote:
> > IMHO the problem with classifying RxRPC as a "reliable datagram"
> > socket is that even an atomic unidirectional communication isn't a
> > single datagram, it's at least 3; there is shared connection state
>
> Thats fine. Any *reliable* protocol send
> IMHO the problem with classifying RxRPC as a "reliable datagram"
> socket is that even an atomic unidirectional communication isn't a
> single datagram, it's at least 3; there is shared connection state
Thats fine. Any *reliable* protocol sends more than one packet per
message you send. RD
On Mar 16, 2007, at 10:11:41, Alan Cox wrote:
I know what they are; and I don't think that what's available
covers it.
and use a proper standard socket type.
Assuming that that list is exhaustive...
SOCK_RDM seems to match perfectly well here. The point isn't to
enumerate everything in
> I know what they are; and I don't think that what's available covers it.
>
> > and use a proper standard socket type.
>
> Assuming that that list is exhaustive...
SOCK_RDM seems to match perfectly well here. The point isn't to enumerate
everything in the universe the point is to find "works li
Alan Cox <[EMAIL PROTECTED]> wrote:
> So your messages are neither reliable not unreliable, nor ordered, nor
> unordered.
If you look at the LHS of each of your list of mappings again, you'll see
you've made an assumption there in considering it to be an exhaustive list.
You've assumed a service
On Fri, 16 Mar 2007 14:23:13 +
David Howells <[EMAIL PROTECTED]> wrote:
> Alan Cox <[EMAIL PROTECTED]> wrote:
>
> > If your messages are datagrams and unreliable -> SOCK_DGRAM
>
> Nope.
>
> > If your messages are datagrams and reliable -> SOCK_RDM
>
> Nope.
>
> > If your messages are data
Alan Cox <[EMAIL PROTECTED]> wrote:
> If your messages are datagrams and unreliable -> SOCK_DGRAM
Nope.
> If your messages are datagrams and reliable -> SOCK_RDM
Nope.
> If your messages are datagrams, reliable and ordered -> SOCK_SEQPACKET
Nope.
> If your messages are streams of bits, relia
> Sockets of AF_RXRPC family are:
>
> (1) created as type SOCK_RPC;
There is no such socket type and please don't invent one
If your messages are datagrams and unreliable -> SOCK_DGRAM
If your messages are datagrams and reliable -> SOCK_RDM
If your messages are datagrams, reliable and ordered
On Fri, Mar 16, 2007 at 12:50:08PM +, David Howells wrote:
> (*) Make fs/afs/ use it and delete the current contents of net/rxrpc/
Having this done would be a really useful use case for getting the code
merged..
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body
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
David Howells <[EMAIL PROTECTED]> wrote:
> 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.
The patches can also be downloaded
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.
The userspace access methods make use of the control data passed to/by
sendmsg()
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.
How about this then:
struct sockaddr_rxrpc {
sa_family_t srx_family;
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> Because it is protocol (such as ipv4 or ipv6) dependent.
Hmmm... I had thought of RxRPC being very transport dependent, being rather
tied to UDPv4, though probably simply extensible to UDPv6. However, as long
as the transport-layer header is remove
In article <[EMAIL PROTECTED]> (at Fri, 09 Feb 2007 12:31:23 +), David
Howells <[EMAIL PROTECTED]> says:
> YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
>
> > and make it sure to align on 64-bit word.
>
> The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
> address
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> and make it sure to align on 64-bit word.
The first part of sockaddr_rxrpc is exactly 64 bits; then comes the transport
address, so that's okay.
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or s
In article <[EMAIL PROTECTED]> (at Fri, 09 Feb 2007 10:31:34 +), David
Howells <[EMAIL PROTECTED]> says:
> YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
>
> > This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> > Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
YOSHIFUJI Hideaki <[EMAIL PROTECTED]> wrote:
> This sockaddr_rxrpc{} should NOT include sockaddr_in{} directly.
> Please use sockaddr_storage{} (or sockaddr{}, maybe), and make it
> sure to align on 64-bit word.
That won't work. That would then make the address larger than the maximum
size (ie:
From: YOSHIFUJI Hideaki <[EMAIL PROTECTED]>
Date: Fri, 09 Feb 2007 01:55:39 +0900 (JST)
> In article <[EMAIL PROTECTED]> (at Thu, 08 Feb 2007 16:32:11 +), David
> Howells <[EMAIL PROTECTED]> says:
>
> > (2) A local address can optionally be bound:
> >
> > struct sockaddr_rxrpc srx = {
In article <[EMAIL PROTECTED]> (at Thu, 08 Feb 2007 16:32:11 +), David
Howells <[EMAIL PROTECTED]> says:
> (2) A local address can optionally be bound:
>
> struct sockaddr_rxrpc srx = {
> .srx_family = AF_RXRPC,
> .srx_service= 0, /* we're a client
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.
The userspace access methods make use of the control data passed to/by
sendmsg()
39 matches
Mail list logo
