[PATCH v2 0/6] Some AF_UNIX fixes

[PATCH v2 0/6] Some AF_UNIX fixes

[Ken Brown]

I'm about to push these.  Corinna, please check them when you return.
The only difference between v2 and v1 is that there are a few more
fixes.

I'm trying to help get the AF_UNIX development going again.  I'm
mostly working on the topic/af_unix branch.  But when I find bugs that
exist on master, I'll push those to master and then merge master to
topic/af_unix.

So far what I have on that branch locally (to be pushed shortly) is an
implementation of fhandler_socket_unix::read, which I've tested by
running the srver/client programs from Section 57.2 of Kerrisk's book,
"The Linux Programming Interface".

Ken Brown (6):
  Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed
  Cygwin: fix handling of known reparse points that are not symlinks
  Cygwin: always recognize AF_UNIX sockets as reparse points
  Cygwin: AF_UNIX: socket: set the O_RDWR flag
  Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS
  Cygwin: AF_UNIX: open_pipe: call recv_peer_info

 winsup/cygwin/fhandler.cc             | 11 ++++++++--
 winsup/cygwin/fhandler_socket_unix.cc | 31 +++++++++++++++++----------
 winsup/cygwin/path.cc                 | 27 +++++++++++++++--------
 winsup/cygwin/security.cc             |  8 +++++--
 4 files changed, 53 insertions(+), 24 deletions(-)

-- 
2.28.0

[PATCH v2 1/6] Cygwin: AF_UNIX: use FILE_OPEN_REPARSE_POINT when needed

[Ken Brown]

The following Windows system calls currently fail with
STATUS_IO_REPARSE_TAG_NOT_HANDLED when called on an AF_UNIX socket:

- NtOpenFile in get_file_sd

- NtOpenFile in set_file_sd

- NtCreateFile in fhandler_base::open

Fix this by adding the FILE_OPEN_REPARSE_POINT flag to those calls
when the file is a known reparse point.
---
 winsup/cygwin/fhandler.cc | 11 +++++++++--
 winsup/cygwin/security.cc |  8 ++++++--
 2 files changed, 15 insertions(+), 4 deletions(-)

diff --git a/winsup/cygwin/fhandler.cc b/winsup/cygwin/fhandler.cc
index 82b21aff4..5dbbd4068 100644
--- a/winsup/cygwin/fhandler.cc
+++ b/winsup/cygwin/fhandler.cc
@@ -620,13 +620,20 @@ fhandler_base::open (int flags, mode_t mode)
   else
     create_disposition = (flags & O_CREAT) ? FILE_OPEN_IF : FILE_OPEN;
 
-  if (get_device () == FH_FS)
+  if (get_device () == FH_FS
+#ifdef __WITH_AF_UNIX
+      || get_device () == FH_UNIX
+#endif
+      )
     {
-      /* Add the reparse point flag to known repares points, otherwise we
+      /* Add the reparse point flag to known reparse points, otherwise we
 	 open the target, not the reparse point.  This would break lstat. */
       if (pc.is_known_reparse_point ())
 	options |= FILE_OPEN_REPARSE_POINT;
+    }
 
+  if (get_device () == FH_FS)
+    {
       /* O_TMPFILE files are created with delete-on-close semantics, as well
 	 as with FILE_ATTRIBUTE_TEMPORARY.  The latter speeds up file access,
 	 because the OS tries to keep the file in memory as much as possible.
diff --git a/winsup/cygwin/security.cc b/winsup/cygwin/security.cc
index 468b05164..d48526619 100644
--- a/winsup/cygwin/security.cc
+++ b/winsup/cygwin/security.cc
@@ -65,7 +65,9 @@ get_file_sd (HANDLE fh, path_conv &pc, security_descriptor &sd,
 			   fh ? pc.init_reopen_attr (attr, fh)
 			      : pc.get_object_attr (attr, sec_none_nih),
 			   &io, FILE_SHARE_VALID_FLAGS,
-			   FILE_OPEN_FOR_BACKUP_INTENT);
+			   FILE_OPEN_FOR_BACKUP_INTENT
+			   | pc.is_known_reparse_point ()
+			   ? FILE_OPEN_REPARSE_POINT : 0);
       if (!NT_SUCCESS (status))
 	{
 	  sd.free ();
@@ -232,7 +234,9 @@ set_file_sd (HANDLE fh, path_conv &pc, security_descriptor &sd, bool is_chown)
 				  : pc.get_object_attr (attr, sec_none_nih),
 			       &io,
 			       FILE_SHARE_VALID_FLAGS,
-			       FILE_OPEN_FOR_BACKUP_INTENT);
+			       FILE_OPEN_FOR_BACKUP_INTENT
+			       | pc.is_known_reparse_point ()
+			       ? FILE_OPEN_REPARSE_POINT : 0);
 	  if (!NT_SUCCESS (status))
 	    {
 	      fh = NULL;
-- 
2.28.0

[PATCH v2 2/6] Cygwin: fix handling of known reparse points that are not symlinks

[Ken Brown]

Commit aa467e6e, "Cygwin: add AF_UNIX reparse points to path
handling", changed check_reparse_point_target so that it could return
a positive value on a known reparse point that is not a symlink.  But
some of the code in check_reparse_point that handles this positive
return value was executed unconditionally, when it should have been
executed only for symlinks.

As a result, posixify could be called on a buffer containing garbage,
and check_reparse_point could erroneously return a positive value on a
non-symlink.  This is now fixed so that posixify is only called if the
reparse point is a symlink, and check_reparse_point returns 0 if the
reparse point is not a symlink.

Also fix symlink_info::check to handle this last case, in which
check_reparse_point returns 0 on a known reparse point.
---
 winsup/cygwin/path.cc | 17 ++++++++++++-----
 1 file changed, 12 insertions(+), 5 deletions(-)

diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 638f1adce..2e3208d2d 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2655,11 +2655,15 @@ symlink_info::check_reparse_point (HANDLE h, bool remote)
   /* ret is > 0, so it's a known reparse point, path in symbuf. */
   path_flags |= ret;
   if (ret & PATH_SYMLINK)
-    sys_wcstombs (srcbuf, SYMLINK_MAX + 7, symbuf.Buffer,
-		  symbuf.Length / sizeof (WCHAR));
-  /* A symlink is never a directory. */
-  fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
-  return posixify (srcbuf);
+    {
+      sys_wcstombs (srcbuf, SYMLINK_MAX + 7, symbuf.Buffer,
+		    symbuf.Length / sizeof (WCHAR));
+      /* A symlink is never a directory. */
+      fileattr &= ~FILE_ATTRIBUTE_DIRECTORY;
+      return posixify (srcbuf);
+    }
+  else
+    return 0;
 }
 
 int
@@ -3274,6 +3278,9 @@ restart:
 		&= ~FILE_ATTRIBUTE_DIRECTORY;
 	      break;
 	    }
+	  else if (res == 0 && (path_flags & PATH_REP))
+	    /* Known reparse point but not a symlink. */
+	    goto file_not_symlink;
 	  else
 	    {
 	      /* Volume moint point or unrecognized reparse point type.
-- 
2.28.0

[PATCH v2 3/6] Cygwin: always recognize AF_UNIX sockets as reparse points

[Ken Brown]

If __WITH_AF_UNIX is defined when Cygwin is built, then a named
AF_UNIX socket is represented by a reparse point with a
Cygwin-specific tag and GUID.  Make such files recognizable as reparse
points (but not as sockets) even if __WITH_AF_UNIX is not defined.
That way utilities such as 'ls' and 'rm' still behave reasonably.

This requires two changes:

- Define the GUID __cygwin_socket_guid unconditionally.

- Make check_reparse_point_target return PATH_REP on a reparse point
  of this type if __WITH_AF_UNIX is not defined.
---
 winsup/cygwin/fhandler_socket_unix.cc | 17 +++++++++--------
 winsup/cygwin/path.cc                 | 10 ++++++----
 2 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index d7bb1090e..429aa8a90 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -8,9 +8,17 @@
    Cygwin license.  Please consult the file "CYGWIN_LICENSE" for
    details. */
 
+#include "winsup.h"
+
+GUID __cygwin_socket_guid = {
+  .Data1 = 0xefc1714d,
+  .Data2 = 0x7b19,
+  .Data3 = 0x4407,
+  .Data4 = { 0xba, 0xb3, 0xc5, 0xb1, 0xf9, 0x2c, 0xb8, 0x8c }
+};
+
 #ifdef __WITH_AF_UNIX
 
-#include "winsup.h"
 #include <w32api/winioctl.h>
 #include <asm/byteorder.h>
 #include <unistd.h>
@@ -124,13 +132,6 @@ class af_unix_pkt_hdr_t
 	   (void *)(((PBYTE)(_p)) + AF_UNIX_PKT_OFFSETOF_DATA (_p)); \
 	})
 
-GUID __cygwin_socket_guid = {
-  .Data1 = 0xefc1714d,
-  .Data2 = 0x7b19,
-  .Data3 = 0x4407,
-  .Data4 = { 0xba, 0xb3, 0xc5, 0xb1, 0xf9, 0x2c, 0xb8, 0x8c }
-};
-
 /* Some error conditions on pipes have multiple status codes, unfortunately. */
 #define STATUS_PIPE_NO_INSTANCE_AVAILABLE(status)	\
 		({ NTSTATUS _s = (status); \
diff --git a/winsup/cygwin/path.cc b/winsup/cygwin/path.cc
index 2e3208d2d..4f5f03a76 100644
--- a/winsup/cygwin/path.cc
+++ b/winsup/cygwin/path.cc
@@ -2476,8 +2476,7 @@ check_reparse_point_string (PUNICODE_STRING subst)
 /* Return values:
     <0: Negative errno.
      0: Not a reparse point recognized by us.
-    >0: PATH_SYMLINK | PATH_REP for symlink or directory mount point,
-        PATH_SOCKET | PATH_REP for AF_UNIX socket.
+    >0: Path flags for a recognized reparse point, always including PATH_REP.
 */
 int
 check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
@@ -2618,15 +2617,18 @@ check_reparse_point_target (HANDLE h, bool remote, PREPARSE_DATA_BUFFER rp,
 	}
       return -EIO;
     }
-#ifdef __WITH_AF_UNIX
   else if (rp->ReparseTag == IO_REPARSE_TAG_CYGUNIX)
     {
       PREPARSE_GUID_DATA_BUFFER rgp = (PREPARSE_GUID_DATA_BUFFER) rp;
 
       if (memcmp (CYGWIN_SOCKET_GUID, &rgp->ReparseGuid, sizeof (GUID)) == 0)
+#ifdef __WITH_AF_UNIX
 	return PATH_SOCKET | PATH_REP;
+#else
+        /* Recognize this as a reparse point but not as a socket.  */
+        return PATH_REP;
+#endif
     }
-#endif /* __WITH_AF_UNIX */
   return 0;
 }
 
-- 
2.28.0

[PATCH v2 4/6] Cygwin: AF_UNIX: socket: set the O_RDWR flag

[Ken Brown]

---
 winsup/cygwin/fhandler_socket_unix.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 429aa8a90..0ae7fe125 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -1366,6 +1366,7 @@ fhandler_socket_unix::socket (int af, int type, int protocol, int flags)
   wmem (262144);
   set_addr_family (AF_UNIX);
   set_socket_type (type);
+  set_flags (O_RDWR | O_BINARY);
   if (flags & SOCK_NONBLOCK)
     set_nonblocking (true);
   if (flags & SOCK_CLOEXEC)
-- 
2.28.0

[PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS

[Ken Brown]

A successful connection can be indicated by STATUS_SUCCESS or
STATUS_PIPE_CONNECTED.  Previously we were checking only for the
latter.
---
 winsup/cygwin/fhandler_socket_unix.cc | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 0ae7fe125..1a9532fe5 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -1064,6 +1064,7 @@ fhandler_socket_unix::listen_pipe ()
   IO_STATUS_BLOCK io;
   HANDLE evt = NULL;
   DWORD waitret = WAIT_OBJECT_0;
+  int ret = -1;
 
   io.Status = STATUS_PENDING;
   if (!is_nonblocking () && !(evt = create_event ()))
@@ -1085,9 +1086,11 @@ fhandler_socket_unix::listen_pipe ()
     set_errno (EINTR);
   else if (status == STATUS_PIPE_LISTENING)
     set_errno (EAGAIN);
-  else if (status != STATUS_PIPE_CONNECTED)
+  else if (status == STATUS_SUCCESS || status == STATUS_PIPE_CONNECTED)
+    ret = 0;
+  else
     __seterrno_from_nt_status (status);
-  return (status == STATUS_PIPE_CONNECTED) ? 0 : -1;
+  return ret;
 }
 
 ULONG
-- 
2.28.0

[PATCH v2 6/6] Cygwin: AF_UNIX: open_pipe: call recv_peer_info

[Ken Brown]

If open_pipe is called with xchg_sock_info true, call recv_peer_info
in addition to send_sock_info.
---
 winsup/cygwin/fhandler_socket_unix.cc | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/winsup/cygwin/fhandler_socket_unix.cc b/winsup/cygwin/fhandler_socket_unix.cc
index 1a9532fe5..9f7f86c47 100644
--- a/winsup/cygwin/fhandler_socket_unix.cc
+++ b/winsup/cygwin/fhandler_socket_unix.cc
@@ -941,7 +941,11 @@ fhandler_socket_unix::open_pipe (PUNICODE_STRING pipe_name, bool xchg_sock_info)
     {
       set_handle (ph);
       if (xchg_sock_info)
-	send_sock_info (false);
+	{
+	  /* FIXME: Should we check for errors? */
+	  send_sock_info (false);
+	  recv_peer_info ();
+	}
     }
   return status;
 }
-- 
2.28.0

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Ken Brown]

On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> I'm about to push these.  Corinna, please check them when you return.
> The only difference between v2 and v1 is that there are a few more
> fixes.
> 
> I'm trying to help get the AF_UNIX development going again.  I'm
> mostly working on the topic/af_unix branch.  But when I find bugs that
> exist on master, I'll push those to master and then merge master to
> topic/af_unix.

FYI to Corinna and anyone else interested in AF_UNIX development.  After pushing 
a few patches to the topic/af_unix branch I did some cleanup (locally) and 
merged master into the topic branch.  I don't want to do a forced push and risk 
messing up the branch, so I've created a new branch, topic/af_unix_new, and will 
do all further work there until Corinna returns and decides how we should proceed.

Ken

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Corinna Vinschen]

On Oct  4 12:49, Ken Brown via Cygwin-patches wrote:
> I'm about to push these.  Corinna, please check them when you return.
> The only difference between v2 and v1 is that there are a few more
> fixes.
> 
> I'm trying to help get the AF_UNIX development going again.  I'm
> mostly working on the topic/af_unix branch.  But when I find bugs that
> exist on master, I'll push those to master and then merge master to
> topic/af_unix.
> 
> So far what I have on that branch locally (to be pushed shortly) is an
> implementation of fhandler_socket_unix::read, which I've tested by
> running the srver/client programs from Section 57.2 of Kerrisk's book,
> "The Linux Programming Interface".

Oh boy, this is SOOOO great!  Thanks for working on that!


Corinna

Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS

[Corinna Vinschen]

On Oct  4 12:49, Ken Brown via Cygwin-patches wrote:
> A successful connection can be indicated by STATUS_SUCCESS or
> STATUS_PIPE_CONNECTED.

THanks for catching but... huh?  How does Windows generate two different
status codes for the same result from the same function?


Corinna

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Corinna Vinschen]

On Oct  8 17:36, Ken Brown via Cygwin-patches wrote:
> On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> > I'm about to push these.  Corinna, please check them when you return.
> > The only difference between v2 and v1 is that there are a few more
> > fixes.
> > 
> > I'm trying to help get the AF_UNIX development going again.  I'm
> > mostly working on the topic/af_unix branch.  But when I find bugs that
> > exist on master, I'll push those to master and then merge master to
> > topic/af_unix.
> 
> FYI to Corinna and anyone else interested in AF_UNIX development.  After
> pushing a few patches to the topic/af_unix branch I did some cleanup
> (locally) and merged master into the topic branch.  I don't want to do a
> forced push and risk messing up the branch, so I've created a new branch,
> topic/af_unix_new, and will do all further work there until Corinna returns
> and decides how we should proceed.

No, that's ok, just force push.


Thanks,
Corinna

Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS

[Ken Brown]

On 10/13/2020 7:28 AM, Corinna Vinschen wrote:
> On Oct  4 12:49, Ken Brown via Cygwin-patches wrote:
>> A successful connection can be indicated by STATUS_SUCCESS or
>> STATUS_PIPE_CONNECTED.
> 
> THanks for catching but... huh?  How does Windows generate two different
> status codes for the same result from the same function?

I think (but I'd have to recheck) that if the pipe is already connected when 
NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED.  But 
if you first get STATUS_PENDING and then set status = io.Status after 
completion, then the result is STATUS_SUCCESS.

I might not have that exactly right.  All I remember for sure is that I was 
debugging a listen_pipe failure, and it turned out to be due to STATUS_SUCCESS 
being treated as an error condition.

Ken

Re: [PATCH v2 5/6] Cygwin: AF_UNIX: listen_pipe: check for STATUS_SUCCESS

[Corinna Vinschen]

On Oct 13 13:18, Ken Brown via Cygwin-patches wrote:
> On 10/13/2020 7:28 AM, Corinna Vinschen wrote:
> > On Oct  4 12:49, Ken Brown via Cygwin-patches wrote:
> >> A successful connection can be indicated by STATUS_SUCCESS or
> >> STATUS_PIPE_CONNECTED.
> > 
> > THanks for catching but... huh?  How does Windows generate two different
> > status codes for the same result from the same function?
> 
> I think (but I'd have to recheck) that if the pipe is already connected when 
> NtFsControlFile is called, then the latter returns STATUS_PIPE_CONNECTED.  But 
> if you first get STATUS_PENDING and then set status = io.Status after 
> completion, then the result is STATUS_SUCCESS.

Ah, ok.  I guess I just missed this scenario for some reason.


Thanks,
Corinna

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Ken Brown]

On 10/13/2020 7:49 AM, Corinna Vinschen wrote:
> On Oct  8 17:36, Ken Brown via Cygwin-patches wrote:
>> On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
>>> I'm about to push these.  Corinna, please check them when you return.
>>> The only difference between v2 and v1 is that there are a few more
>>> fixes.
>>>
>>> I'm trying to help get the AF_UNIX development going again.  I'm
>>> mostly working on the topic/af_unix branch.  But when I find bugs that
>>> exist on master, I'll push those to master and then merge master to
>>> topic/af_unix.
>>
>> FYI to Corinna and anyone else interested in AF_UNIX development.  After
>> pushing a few patches to the topic/af_unix branch I did some cleanup
>> (locally) and merged master into the topic branch.  I don't want to do a
>> forced push and risk messing up the branch, so I've created a new branch,
>> topic/af_unix_new, and will do all further work there until Corinna returns
>> and decides how we should proceed.
> 
> No, that's ok, just force push.

OK, I've done that now.  The branch contains a few sendmsg fixes, a first cut of 
a recvmsg implementation, and a merge from master.  I've done some testing of 
recvmsg, but many things are not yet tested.  I'll work on continued testing next.

Are you aware of any test suite that I could run?  I've been using examples from 
Kerrisk's book, because that's what I read to learn the basics of sockets.  But 
those are just examples and are not meant to be comprehensive.

Ken

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Mark Geisert]

Ken Brown via Cygwin-patches wrote:
> Are you aware of any test suite that I could run?  I've been using examples from 
> Kerrisk's book, because that's what I read to learn the basics of sockets.  But 
> those are just examples and are not meant to be comprehensive.

In ye olden days I used to use Stevens+Rago "Advanced Programming In The Unix 
Environment, 2nd ed.".  Chapter 17 covers UNIX domain sockets as advanced IPC. 
It's more examples but maybe they hit different corners of the playing field.  I 
don't know of a test suite or even a standalone program that exercises AF_UNIX.

..mark

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Brian Inglis]

On 2020-10-14 22:19, Mark Geisert wrote:
> Ken Brown via Cygwin-patches wrote:
>> Are you aware of any test suite that I could run?  I've been using examples
>> from Kerrisk's book, because that's what I read to learn the basics of
>> sockets.  But those are just examples and are not meant to be comprehensive.
> 
> In ye olden days I used to use Stevens+Rago "Advanced Programming In The Unix
> Environment, 2nd ed.".  Chapter 17 covers UNIX domain sockets as advanced IPC.
> It's more examples but maybe they hit different corners of the playing field.  I
> don't know of a test suite or even a standalone program that exercises AF_UNIX.

The late author's Unix Network Programming has been updated by his co-authors to
Vol 1 3rd ed. and has some Unix domain AF_UNIX/AF_LOCAL content:

	https://github.com/unpbook/unpv13e.git

Cygwin utilities nc, nttcp, socat, ttcp are available, some with Unix domain
AF_UNIX/AF_LOCAL support and tests;

replaces netperf.org web site, HP copyright somewhat non-free, includes Unix
domain AF_UNIX//AF_LOCAL tests, but I never tried it under Cygwin:

	https://hewlettpackard.github.io/netperf/
	https://github.com/HewlettPackard/netperf.git

also came across a mention of:

	https://github.com/rigtorp/ipc-bench.git

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

Re: [PATCH v2 0/6] Some AF_UNIX fixes

[Corinna Vinschen]

On Oct 14 12:39, Ken Brown via Cygwin-patches wrote:
> On 10/13/2020 7:49 AM, Corinna Vinschen wrote:
> > On Oct  8 17:36, Ken Brown via Cygwin-patches wrote:
> > > On 10/4/2020 12:49 PM, Ken Brown via Cygwin-patches wrote:
> > > > I'm about to push these.  Corinna, please check them when you return.
> > > > The only difference between v2 and v1 is that there are a few more
> > > > fixes.
> > > > 
> > > > I'm trying to help get the AF_UNIX development going again.  I'm
> > > > mostly working on the topic/af_unix branch.  But when I find bugs that
> > > > exist on master, I'll push those to master and then merge master to
> > > > topic/af_unix.
> > > 
> > > FYI to Corinna and anyone else interested in AF_UNIX development.  After
> > > pushing a few patches to the topic/af_unix branch I did some cleanup
> > > (locally) and merged master into the topic branch.  I don't want to do a
> > > forced push and risk messing up the branch, so I've created a new branch,
> > > topic/af_unix_new, and will do all further work there until Corinna returns
> > > and decides how we should proceed.
> > 
> > No, that's ok, just force push.
> 
> OK, I've done that now.  The branch contains a few sendmsg fixes, a first
> cut of a recvmsg implementation, and a merge from master.  I've done some
> testing of recvmsg, but many things are not yet tested.  I'll work on
> continued testing next.

This is sooo great!

> from Kerrisk's book, because that's what I read to learn the basics of
> sockets.  But those are just examples and are not meant to be comprehensive.

What Mark and Brian said, Stevens' book is quite nice, and there's
code available.  I downloaded the tar file with all code examples
way back when, but apparently the code is on github now, as Brian
pointed out.


Thanks,
Corinna