From: Jan M. <jmo...@te...> - 2014-09-17 09:29:16
|
Hi, there have been at least two questions about supporting IPv6 in SBCL on the usocket list. I'v had the attached patch floating around for some time and would like to take this opportunity to clean it up and commit it. I think, I mainly have to work on address parsing, tests and documentation. What do you think? Is the file (re)organisation acceptable? Did I miss anything important for basic IPv6 support? Also, I think Stas mentioned some sb-bsd-sockets changes, he is going to perform. Is there a need for coordination? Thanks in advance, Jan |
From: Stas B. <sta...@gm...> - 2014-09-18 10:30:56
|
Jan Moringen <jmo...@te...> writes: > Hi, > > there have been at least two questions about supporting IPv6 in SBCL on > the usocket list. > > I'v had the attached patch floating around for some time and would like > to take this opportunity to clean it up and commit it. I think, I mainly > have to work on address parsing, tests and documentation. > > What do you think? Is the file (re)organisation acceptable? Did I miss > anything important for basic IPv6 support? > > Also, I think Stas mentioned some sb-bsd-sockets changes, he is going to > perform. Is there a need for coordination? I don't think I have anything lined up for sb-bsd-sockets, so, no merge conflicts there. -- With best regards, Stas. |
From: Jan M. <jmo...@te...> - 2014-09-20 13:56:37
|
On Thu, 2014-09-18 at 14:30 +0400, Stas Boukarev wrote: > Jan Moringen <jmo...@te...> writes: > > > Also, I think Stas mentioned some sb-bsd-sockets changes, he is going to > > perform. Is there a need for coordination? > I don't think I have anything lined up for sb-bsd-sockets, so, no merge > conflicts there. Thanks. Updated patch is at http://paste.lisp.org/display/143795. |
From: Jan M. <jmo...@te...> - 2014-09-24 00:48:54
Attachments:
0001-sb-bsd-sockets-Minor-mostly-cosmetic-changes.patch
0002-sb-bsd-sockets-Separate-internet-protocol-sockets-in.patch
0003-sb-bsd-sockets-Move-protocol-into-new-file-protocol..patch
0004-sb-bsd-sockets-New-macros-WITH-SOCKET-FD-AND-ADDRESS.patch
0005-sb-bsd-sockets-New-macros-SOCKET-ADDRINFO-ERROR-CASE.patch
0006-sb-bsd-sockets-Initial-addition-of-IPv6-support-in-i.patch
0007-sb-bsd-sockets-Version-bump-ipv6-documentation-and-N.patch
|
On Sat, 2014-09-20 at 15:56 +0200, Jan Moringen wrote: > Updated patch is at http://paste.lisp.org/display/143795. Attached is the best patch I can currently produce while maintaining backwards compatibility. Tests pass (even the #+internet-available ones after I installed and configured inetd). Noteworthy points: * The extended GET-HOST-BY-NAME sucks: it returns a HOST-ENT instance with IPv4 addresses as its first return value (like before) and a HOST-ENT with IPv6 addresses as its second return value. * IPv6 support is enabled on #+(not win32) but I could only test on Linux. * (Un)parsing of IPv6 addresses uses the foreign functions inet_{ntop,pton} which may lead to portability problems. This could be solved, for example, by stealing code from iolib, but I'm not sure about license compatibility. Christophe, how should we proceed? The original plan was getting the changes into the upcoming release (mostly to support Hans' IPv6 extension of usocket). Should I push now to allow people to test the changes and try to fix all surfacing problems before the release? Or should we wait until after the release? Thanks and kind regards, Jan |
From: Christophe R. <cs...@ca...> - 2014-09-24 07:03:20
|
Jan Moringen <jmo...@te...> writes: > Christophe, how should we proceed? The original plan was getting the > changes into the upcoming release (mostly to support Hans' IPv6 > extension of usocket). Should I push now to allow people to test the > changes and try to fix all surfacing problems before the release? Or > should we wait until after the release? I think I'm a little uncomfortable about this: it seems like the kind of thing that would cause build failures / sb-bsd-sockets test failures, simply because we haven't tested hard enough. So, unless we hear squeals of pain from Hans that this can't wait, I would suggest holding off until early in the next cycle, which promises to be wildly exciting. Also, clearly we need to deprecate get-host-by-name in its current form. That means we can have a long bikeshedding discussion about what a new interface should look like! Bonus points if it is obvious how it would support ipv17. Cheers, Christophe |
From: Stelian I. <sio...@cd...> - 2014-09-24 10:03:12
Attachments:
signature.asc
|
On Wed, 2014-09-24 at 02:48 +0200, Jan Moringen wrote: > On Sat, 2014-09-20 at 15:56 +0200, Jan Moringen wrote: [...] > * (Un)parsing of IPv6 addresses uses the foreign functions > inet_{ntop,pton} which may lead to portability problems. This > could be solved, for example, by stealing code from iolib, but > I'm not sure about license compatibility. All code in IOlib is MIT-licenced, and therefore compatible with SBCL. -- Stelian Ionescu a.k.a. fe[nl]ix Quidquid latine dictum sit, altum videtur. |
From: Jan M. <jmo...@te...> - 2014-09-24 10:22:35
|
On Wed, 2014-09-24 at 11:46 +0200, Stelian Ionescu wrote: > On Wed, 2014-09-24 at 02:48 +0200, Jan Moringen wrote: > > On Sat, 2014-09-20 at 15:56 +0200, Jan Moringen wrote: > [...] > > * (Un)parsing of IPv6 addresses uses the foreign functions > > inet_{ntop,pton} which may lead to portability problems. This > > could be solved, for example, by stealing code from iolib, but > > I'm not sure about license compatibility. > > All code in IOlib is MIT-licenced, and therefore compatible with SBCL. That's good to know. Thanks. |