lwip-users
[Top][All Lists]
Advanced

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

RE : RE : [lwip-users] lwIP Manual


From: Frédéric BERNON
Subject: RE : RE : [lwip-users] lwIP Manual
Date: Sat, 19 May 2007 12:06:27 +0200

Ok, so, I propose to decide that lwIP internal features are not designed to be used directly by application like sys_timeout (see https://savannah.nongnu.org/bugs/?1902, comment#28).
 
 
 
====================================
Frédéric BERNON
HYMATOM SA
Chef de projet informatique
Microsoft Certified Professional
Tél. : +33 (0)4-67-87-61-10
Fax. : +33 (0)4-67-70-85-44
Email : address@hiddenr
Web Site : http://www.hymatom.fr
====================================
P Avant d'imprimer, penser à l'environnement
 
-----Message d'origine-----
De : address@hidden [mailto:address@hidden De la part de Goldschmidt Simon
Envoyé : samedi 19 mai 2007 10:54
À : address@hidden
Objet : WG: RE : [lwip-users] lwIP Manual

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

Attachment: Frédéric BERNON.vcf
Description: Frédéric BERNON.vcf


reply via email to

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