On Thu, 2008-17-07 at 02:31 +0200, Andreas Henriksson wrote:Thats just how it rolls. The receiver(kernel in this case, but it could be some other user space user) returning a zero means success. Essentially zero is an (Positive) ACK. The receiver returning a non-zero implies a failure. Essentially a N(egative) ACK. In the case of a NACK, the kernel must return you the original message header you sent (similar to the way some icmp messages behave). The returned error code is a standard errno - if you sent a bad config you may get an EINVAL back. The sender combines the errno + the header to figure out what went wrong. Does that make sense? So the kernel fix is required (as Stephen noted). cheers, jamal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Amit K. Arora | [RFC] Heads up on sys_fallocate() |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Linus Torvalds | Linux 2.6.25-rc4 |
| Greg KH | Linux 2.6.25.10 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Ilpo Järvinen | Re: Strange Application bug, race in MSG_PEEK complaints (was: Bug#513695: fetchma... |
