I'd like that idea of Frédéric and me go in: accessing sockets
from
multiple threads. I'll create a bug-tracker item for it. I don't know
if
it changes the API, but it will certainly break ports.
Other than
that, there's
- the timestamp thing (big change)
- the etharp/ip_frag
thing (no ports change, only internal)
- Also I'd like to put a little time
into a "code-review" of the
sequential API, I think there are still some
pitfalls (should I make
that a task?).
- Integrating checksum-on-copy
would be a huge benefit for the next
release (the user gets better
performance at least for TCP send "for
free").
- Integrating support for
MACs that support on-the-fly byte-order
conversion is considered low by
me
In general, I think as there's no real time pressure, I'd like
all
currently listed tasks to go in
;-)
Simon
-----Originalnachricht-----
Von:
address@hidden
An: Mailing
list for lwIP users
Gesendet: 18.05.2007 17:57
Betreff: Re: RE :
[lwip-users] lwIP Manual
On Fri, 2007-05-18 at 17:45 +0200, Frédéric
BERNON wrote:
> Kieran,
>
> Because lot of things change
these last months, with lot of new
> options, I think that will be good
to define what tasks/bugs/items
> have to be closed for the next
release, and when this release will be
> stopped, we could do the
documentation.
OK. I think in general terms for the next release
I'd like to
prioritise anything we foresee that will alter any of our
APIs. We've
already made a number of changes recently that will break
ports. I'd
rather get all the port-breakage we think we need into
this release, and
then any future releases would be less painful for the
porters.
To this end, it would be a great help if all these issues were
in the
savannah task/patch/bug system. If anyone knows or can think
of
anything that should be in there and is not, please add it.
I
should come up with a way to mark the tasks/patches/bugs that we want
to
fix for the release, and then magic some spare time to let me
do
it!
There is also little clamour from users to get the
recent stuff into a
stable form for use, so we needn't hurry a release
out. We can afford
to take our time, fix more bugs, and get some more
of the tasks done.
Leon has volunteered to help with the actual
mechanics of the release as
he has some experience of it, which would be
very helpful, but we're not
there yet.
There will of course need to
be a couple of release candidates, together
with testing, to make sure we
don't release something unusable
by
others.
Kieran
_______________________________________________
lwip-users
mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users