From e9718757c801f21cfa4b80052703e55ab208efa5 Mon Sep 17 00:00:00 2001
From: Gregory Nutt <gnutt@nuttx.org>
Date: Sun, 23 Nov 2014 12:52:18 -0600
Subject: Update comments and read me

---
 nuttx/TODO                           | 31 ++++++++++++++++++++++++-------
 nuttx/net/netdev/netdev_findbyaddr.c |  2 +-
 nuttx/net/udp/udp_input.c            | 16 +++++++++++++++-
 3 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/nuttx/TODO b/nuttx/TODO
index 0c2bcb794..5475370f6 100644
--- a/nuttx/TODO
+++ b/nuttx/TODO
@@ -1,4 +1,4 @@
-NuttX TODO List (Last updated November 22, 2014)
+NuttX TODO List (Last updated November 23, 2014)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 This file summarizes known NuttX bugs, limitations, inconsistencies with
@@ -15,7 +15,7 @@ nuttx/
   (8)  Kernel/Protected Builds
   (4)  C++ Support
   (6)  Binary loaders (binfmt/)
- (12)  Network (net/, drivers/net)
+ (13)  Network (net/, drivers/net)
   (4)  USB (drivers/usbdev, drivers/usbhost)
  (10)  Libraries (libc/, )
  (11)  File system/Generic drivers (fs/, drivers/)
@@ -830,15 +830,32 @@ o Network (net/, drivers/net)
                connections promptly.
 
   Title:       INTERRUPT LEVEL PROCESSING IN ETHERNET DRIVERS
-  Description: Too many Ethernet drivers do interrupt-level processing with the network
-               stack.  The network stack supports either interrupt level processing or
-               normal task level processing (depending on CONFIG_NET_NOINTS).  This is
-               really a very bad use of CPU resources;  All of the network stack processing
-               should be more to a work queue (and, all use of CONFIG_NET_NOINTS=n should
+  Description: Too many Ethernet drivers do interrupt-level processing with
+               the network stack.  The network stack supports either interrupt
+               level processing or normal task level processing (depending on
+               CONFIG_NET_NOINTS).  This is really a very bad use of CPU
+               resources;  All of the network stack processing should be more
+               to a work queue (and, all use of CONFIG_NET_NOINTS=n should
                be eliminated).
   Status:      Open
   Priority:    Pretty high if you want a well behaved system.
 
+  Title:       UDP MULTICAST RECEPTION
+  Description: The logic in udp_input() expects either a single receive socket or
+               none at all.  However, multiple sockets should be capable of
+               receiving a UDP datagram (multicast reception).  This could be
+               handled easily by something like:
+
+                for (conn = NULL; conn = udp_active (pbuf, conn); )
+
+               If the callback logic that receives a packet responds with an
+               outgoing packet, then it will over-write the received buffer,
+               however.  recvfrom() will not do that, however.  We would have
+               to make that the rule: Recipients of a UDP packet must treat
+               the packet as read-only.
+  Status:      Open
+  Priority:    Low, unless your logic depends on that behavior.
+
 o USB (drivers/usbdev, drivers/usbhost)
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
diff --git a/nuttx/net/netdev/netdev_findbyaddr.c b/nuttx/net/netdev/netdev_findbyaddr.c
index f1ea3712a..0f0abe4b4 100644
--- a/nuttx/net/netdev/netdev_findbyaddr.c
+++ b/nuttx/net/netdev/netdev_findbyaddr.c
@@ -233,7 +233,7 @@ FAR struct net_driver_s *netdev_findbyaddr(const net_ipaddr_t ripaddr)
 #ifndef CONFIG_NET_MULTILINK
    /* If there is only a single, registered network interface, then the
     * decision is pretty easy.  Use that device and its default router
-    * address.  Hmmm... it is almost certainly wrong, however.
+    * address.
     */
 
    dev = g_netdevices;
diff --git a/nuttx/net/udp/udp_input.c b/nuttx/net/udp/udp_input.c
index 5a78baa1f..99b16761f 100644
--- a/nuttx/net/udp/udp_input.c
+++ b/nuttx/net/udp/udp_input.c
@@ -127,7 +127,21 @@ int udp_input(FAR struct net_driver_s *dev)
   else
 #endif
     {
-      /* Demultiplex this UDP packet between the UDP "connections". */
+      /* Demultiplex this UDP packet between the UDP "connections".
+       *
+       * REVISIT:  The logic here expects either a single receive socket or
+       * none at all.  However, multiple sockets should be capable of
+       * receiving a UDP datagram (multicast reception).  This could be
+       * handled easily by something like:
+       *
+       *   for (conn = NULL; conn = udp_active (pbuf, conn); )
+       *
+       * If the callback logic that receives a packet responds with an
+       * outgoing packet, then it will over-write the received buffer,
+       * however.  recvfrom() will not do that, however.  We would have to
+       * make that the rule: Recipients of a UDP packet must treat the
+       * packet as read-only.
+       */
 
       conn = udp_active(pbuf);
       if (conn)
-- 
cgit v1.2.3