RTT上移植的lwip为何不用单一进程维护eth设备呢

研究了一下RTT上移植的lwip
1、问题，为何不用单一进程维护eth设备？
既然采用了ipc来传递报文，为何不用单一进程维护eth设备呢？我看过一些wlan的驱动，设备主要都是有一个主进程维护（大致采用switch(msg_get(mbox)){case tx: case rx: case other:}这种结构），收包、发包、命令都是在这个进程中完成，状态变更的信息也是从这个进程发出；对设备的访问在时域上天然不会重入；进程功能上也划分的很清晰；想听听您移植中的一些想法。
2、建议，让lwip来处理arp是不是更好？
先上代码(从google仓库新获取)，
rrt中的eth_input()
err_t eth_input(struct pbuf *p, struct netif *inp)
{
  struct eth_hdr *ethhdr;
  if(p != RT_NULL)
  {
#ifdef LINK_STATS
    LINK_STATS_INC(link.recv);
#endif /* LINK_STATS */
    ethhdr = p->payload;
    switch(htons(ethhdr->type))
    {
    case ETHTYPE_IP:
      etharp_ip_input(inp, p);
      pbuf_header(p, -14);
      tcpip_input(p, inp);
      break;
    case ETHTYPE_ARP:
      etharp_arp_input(inp, (struct eth_addr *)inp->hwaddr, p);
      break;
    default:
      pbuf_free(p);
      p = RT_NULL;
      break;
    }
  }
  return ERR_OK;
}
rtt移植的lwip接收数据包是由独立进程完成，在获取pbuf之后，调用eth_input（）交付数据包；
eth_input()区分对待ARP和IP报文，采用不同方式处理；很明显，ARP的处理是在本地完成的，而且可能会涉及到发送报文的操作；
这种处理方式我觉得不妥，
首先，从功能、代码的划分隔离度角度上看，接收报文的线程牵扯到太多tcpip 的协议工作，不能体现进程功能的独立性；
其次，从功能上看，由于arp操作可能会涉及到发包，那么会看到有两个进程可以发包，两者同时存在，职能不独立，不美观。
建议，将arp的处理转移到tcpip主进程中来处理，官网下载的lwip130，其中：
来自于 Ethernetif.c
static void
ethernetif_input(struct netif *netif)
{
  struct ethernetif *ethernetif;
  struct eth_hdr *ethhdr;
  struct pbuf *p;
  ethernetif = netif->state;
  /* move received packet into a new pbuf */
  p = low_level_input(netif);
  /* no packet could be read, silently ignore this */
  if (p == NULL) return;
  /* points to packet payload, which starts with an Ethernet header */
  ethhdr = p->payload;
  switch (htons(ethhdr->type)) {
  /* IP or ARP packet? */
  case ETHTYPE_IP:
  case ETHTYPE_ARP:
#if PPPOE_SUPPORT
  /* PPPoE packet? */
  case ETHTYPE_PPPOEDISC:
  case ETHTYPE_PPPOE:
#endif /* PPPOE_SUPPORT */
    /* full packet send to tcpip_thread to process */
    if (netif->input(p, netif)!=ERR_OK)
     { LWIP_DEBUGF(NETIF_DEBUG, ("ethernetif_input: IP input error
"));
       pbuf_free(p);
       p = NULL;
     }
    break;
  default:
    pbuf_free(p);
    p = NULL;
    break;
  }
}
可以看到，不管是ip arp，底层接收到包后，直接转移到tcpip_thread（）中了(主进程中有处理arp相关的部分)。