[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [task #6969] Review usage of conn->err in netconn layer

From: Jonathan Larmour
Subject: [lwip-devel] [task #6969] Review usage of conn->err in netconn layer
Date: Mon, 26 Nov 2007 18:00:04 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060513 Fedora/1.0.8-1.1.fc3.1.legacy Firefox/1.0.8

Follow-up Comment #24, task #6969 (project lwip):

> So, perhaps can you give your list about what is "fatal", and
> what is not?

Well, that was my point :-) ... sometimes the same sort of error may be fatal
or not.

For example, memory errors would be non-fatal - fine. For example one I have
in my driver is if someone tries to send a packet where the pbuf chain is more
than the driver can cope with. That packet can never ever be sent as it is,
but ERR_MEM doesn't seem right because retrying will never help. But at the
same time returning ERR_IF marks the whole connection as dead (which is what
happens in current code until this task is complete) which doesn't seem right
either because other packets would work. What I might like is something like a
non-fatal ERR_IF.
But I was only suggesting the bitmask as an idea, that's all. And to be
honest, the problem above isn't such a big problem. You don't have to agree,
in which case what you had in IRC seemed okay. I guess what really matters is
consistency and making sure everyone knows what errors really mean.

> About the bitmask, the problem could be with err_to_errno_table
> in sockets.c. But we could mask it (bit 6) I think.

Yes, that's also what I was thinking of.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]