Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*IPV6\s+RFC3542\s+compliance\s+\[PATCH\]\s*$/: 28 ]

Total 28 documents matching your query.

1. IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: David Stevens <dlstevens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 13:48:26 -0600
I've been looking at RFC 3542 (Advanced Sockets API) compliance, and found the following: ("x" is one of {PKTINFO, HOPLIMIT, RTHDR, DSTOPTS, TCLASS }) What RFC 3542 says: 1) IPV6_x as socket options
/archives/netdev/2005-06/msg00199.html (28,430 bytes)

2. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 07 Jun 2005 14:19:22 +0900 (JST)
Well, this breaks API. Please rename old options, say: IPV6_PKTINFO => IPV6_2292PKTINFO IPV6_HOPLIMIT => IPV6_2292HOPLIMI IPV6_RTHDR => IPV6_2292RTHDR IPV6_DSTOPTS => IPV6_2292DSTOPTS And, add alloca
/archives/netdev/2005-06/msg00232.html (10,583 bytes)

3. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: xxxxxx>
Date: Mon, 6 Jun 2005 23:25:28 -0700
RFC 3542 broke the API-- they've defined options with the same name, but different semantics. And those same binaries would not work when recompiled, because the option names in the source would matc
/archives/netdev/2005-06/msg00235.html (10,249 bytes)

4. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: xxxxxx>
Date: Tue, 07 Jun 2005 15:33:59 +0900 (JST)
It is not good at all to break API at this moment (2.6.x). Portable applications do like this: // RFC2292bis // RFC2292 --yoshfuji
/archives/netdev/2005-06/msg00236.html (9,922 bytes)

5. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: xxxxxxxxxxxxxx>
Date: Mon, 6 Jun 2005 23:35:46 -0700
I should've said clearly; with the patch I submitted as-is, all old binaries should return EINVAL on the socket options that have changed. That's because all of those (except the new IPV6_TCLASS, wh
/archives/netdev/2005-06/msg00237.html (9,083 bytes)

6. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: ens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 23:50:16 -0700
I don't understand. If they do this, they'll work already when recompiled (with the patch I sent), won't they? If they don't do this, old binaries will return EINVAL on the setsockopt() calls that h
/archives/netdev/2005-06/msg00238.html (9,444 bytes)

7. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: ens@xxxxxxxxxx>
Date: Tue, 07 Jun 2005 16:05:21 +0900 (JST)
Yes (or they should do so before your favorite distro start shipping with new constants). We can still keep old binaries if we renumber. This is important point. e.g. people, including myself, can ke
/archives/netdev/2005-06/msg00239.html (10,295 bytes)

8. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: oshfuji@xxxxxxxxxxxxxx>
Date: Tue, 7 Jun 2005 00:40:28 -0700
kernels. But old binaries won't work with just that change (and making them work is independent of changing the numbers). For example, old binary: IPV6_RTHDR is value 5 it does: on=1; setsockopt(s,
/archives/netdev/2005-06/msg00240.html (10,773 bytes)

9. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: <dlstevens@xxxxxxxxxx>
Date: Tue, 07 Jun 2005 16:47:49 +0900 (JST)
No, kernel should send 5, if application use old API, of course. --yoshfuji
/archives/netdev/2005-06/msg00241.html (10,620 bytes)

10. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: 明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 07 Jun 2005 16:55:36 +0900 (JST)
This can be implemented like this (based on codes from our repository): /* RFC2292bis */ if (np->rxopt.bits.rxhbh && opt->hop) { u8 *ptr = skb->nh.raw + opt->hop; put_cmsg(msg, SOL_IPV6, IPV6_HOPOPTS
/archives/netdev/2005-06/msg00242.html (10,366 bytes)

11. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 7 Jun 2005 01:01:01 -0700
YOSHIFUJI Hideaki / 吉藤英明 <yoshfuji@xxxxxxxxxxxxxx> wrote on 12:47:49 AM: Ok, but this gets back to my point. If the program source doesn't have #ifdefs like you suggested (for example, if it was writ
/archives/netdev/2005-06/msg00243.html (9,970 bytes)

12. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: x>
Date: Tue, 7 Jun 2005 01:04:17 -0700
as writ
/archives/netdev/2005-06/msg00244.html (10,261 bytes)

13. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: x>
Date: Tue, 07 Jun 2005 17:14:23 +0900 (JST)
after it's rec
/archives/netdev/2005-06/msg00245.html (10,612 bytes)

14. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: xxxxxxxxxxx>
Date: Wed, 8 Jun 2005 12:49:36 -0600
myness scores t
/archives/netdev/2005-06/msg00291.html (33,464 bytes)

15. IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: David Stevens <dlstevens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 13:48:26 -0600
I've been looking at RFC 3542 (Advanced Sockets API) compliance, and found the following: ("x" is one of {PKTINFO, HOPLIMIT, RTHDR, DSTOPTS, TCLASS }) What RFC 3542 says: 1) IPV6_x as socket options
/archives/netdev/2005-06/msg00800.html (28,430 bytes)

16. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: YOSHIFUJI Hideaki / <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 07 Jun 2005 14:19:22 +0900 (JST)
Well, this breaks API. Please rename old options, say: IPV6_PKTINFO => IPV6_2292PKTINFO IPV6_HOPLIMIT => IPV6_2292HOPLIMI IPV6_RTHDR => IPV6_2292RTHDR IPV6_DSTOPTS => IPV6_2292DSTOPTS And, add alloca
/archives/netdev/2005-06/msg00833.html (10,713 bytes)

17. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: David Stevens <dlstevens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 23:25:28 -0700
RFC 3542 broke the API-- they've defined options with the same name, but different semantics. And those same binaries would not work when recompiled, because the option names in the source would matc
/archives/netdev/2005-06/msg00836.html (10,290 bytes)

18. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: YOSHIFUJI Hideaki / <yoshfuji@xxxxxxxxxxxxxx>
Date: Tue, 07 Jun 2005 15:33:59 +0900 (JST)
It is not good at all to break API at this moment (2.6.x). Portable applications do like this: // RFC2292bis // RFC2292 --yoshfuji
/archives/netdev/2005-06/msg00837.html (10,093 bytes)

19. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: David Stevens <dlstevens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 23:35:46 -0700
PS - I should've said clearly; with the patch I submitted as-is, all old binaries should return EINVAL on the socket options that have changed. That's because all of those (except the new IPV6_TCLASS
/archives/netdev/2005-06/msg00838.html (9,148 bytes)

20. Re: IPV6 RFC3542 compliance [PATCH] (score: 1)
Author: David Stevens <dlstevens@xxxxxxxxxx>
Date: Mon, 6 Jun 2005 23:50:16 -0700
I don't understand. If they do this, they'll work already when recompiled (with the patch I sent), won't they? If they don't do this, old binaries will return EINVAL on the setsockopt() calls that h
/archives/netdev/2005-06/msg00839.html (9,485 bytes)

Current List: 1 - 20
Page: [1] [2]
This search system is powered by Namazu